A monitor for every object
Robert Jacques
sandford at jhu.edu
Fri Feb 4 20:08:18 PST 2011
On Fri, 04 Feb 2011 07:26:22 -0500, bearophile <bearophileHUGS at lycos.com>
wrote:
> 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.
Hmm... Well, I'd recommend making @nomonitor the default and then only
annotate certain classes @withmonitor, although I'd prefer a different
keyword, say 'shared'. Oh, wait a second. *sigh* Every since it was
decided that a class couldn't contain both shared and non-shared
methods/fields I've been expecting that the monitor and support for
synchronized methods would be removed from Object or at least from
Object's spec. But this is likely a high-cost/low-gain optimization and a
lot of things regarding shared/immutable classes need to be fixed before
it can happen. I do think it should happen, not so much for the word of
memory, but in order to prevent objects not designed to be shared from
being shared. Which is what the 9th circle is talking about.
One of the cool thing about D's monitors, is that by manually setting
them, you can protect multiple objects with a single monitor. So, for a
set of interwoven objects (i.e. trees, etc) you're not acquiring a new
lock every method call and you are not going to have an internal
deadlock/race. This is actually the essential runtime feature of many
ownership systems. (Although, without an actual ownership-type system you
can't elide synchronization entirely)
More information about the Digitalmars-d
mailing list