digitalmars.D - const, invariant, synchronized, write-only, etc...
- Jason House <jason.james.house gmail.com> Oct 05 2007
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.
Oct 05 2007