• Jason House (36/36) Oct 05 2007 A while back, there was a lot of discussion about const and multi-thread...

Jason House <jason.james.house gmail.com> writes:

A while back, there was a lot of discussion about const and multi-threading. 
I'd like to revive part of that discussion.

In a post, Janice Caron suggested classifying certain objects as requiring a
read or write mutex to access them.  This differs from my understanding of how
the synchronized keyword currently works in D which treats an object as either
locked or unlocked.

IMHO, it makes a lot more sense to focus on what code can read/write from/to an
object... Even if for no other reason than to really understand the problem. 
Looking at just behavior by thread, there's 4 questions to answer:
1. Can this thread (ever) read from the object?
2. Can this thread (ever) write to the object?
3. Can a foreign thread (ever) read from this object?
4. Can a foreign thread (ever) write to the object?

Note that I believe an answer of no to question 1 doesn't means that question 2
can't have an answer of yes.  Examples abound in past discussion where someone
wants to write to a log file for debugging, or draw to a raster for graphics. 
By stating that information flows in only one direction, some kind of const
bound can still be applied.

Quickly enumerating the answers to the questions:
NNNN - Useless
YNNN - thread-local.  invariant
NYNN - thread-local.  No term for write-only
YYNN - thread-local.  Non-const data
NNYN - inaccessible
YNYN - invariant
YYYN - synchronized (no read lock required)
NNNY - inaccessible
YNNY - synchronized. const
NYNY - synchronized. No term for write-only
YYNY - synchronized
NNYY - inacessible
YNYY - synchronized, const
YYYY - synchronized

There are really only N useful answers:
a. inaccessible
b. thread-local
c. thread-local write-only
d. thread-local invariant
e. synchronized
f. synchronized write-only
g. synchronized for write, async read
h. synchronized const

When I think about this, it makes a lot of sense, and it starts me down a path
that is far different from what I currently understand of the const and
synchronized design.

Given the enumeration of possible outcomes, it makes sense to have a transitive
property for thread-local storage and for synchronized data.

Synchronized objects can't contain thread-local objects, but I think it's ok
for thread-local or const objects to contain synchronized objects.

This is by no means a complete framework for all of this stuff, but I think it
may help discussion in this area.