I have found an interesting post by Scott Johnson in this Lambda the Ultimate thread: http://lambda-the-ultimate.org/node/724#comment-6621
He says: >9th circle: Concurrent mutable state. The obnoxious practice of mutating >shared state from multiple threads of control, leading into a predictable >cycle of race conditions, deadlocks, and other assorted misbehavior from which >there is no return. And if a correct solution (for synchronization) is found >for a given program, chances are any substantial change to the program will >make it incorrect again. But you won't find it, instead your customer will. >Despite that, reams of code (and TONS of middleware) has been written to try >and make this tractable. And don't get me started on a certain programming >language which starts with "J" that saw fit to make EVERY object have its very >own monitor....< This is just one quotation, but I have found similar comments four or five other times around the Web. So is the design choice of copying this part of the Java design inside D good? I'd like opinions on this topic. Recently I have suggested an optional @nomonitor annotation for D classes (to optionally remove a word from class instances and to reduce class instantiation overhead a bit). Another option is doing the opposite, and defining a @withmonitor annotation where you want a class to have a monitor. Bye, bearophile
