A monitor for every object

[Steven Schveighoffer]

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.

D's monitors are lazily created, so there should be no issue with resource  
allocation.  If you don't ever lock an object instance, it's not going to  
consume any resources.  Most of the time the extra word isn't noticed  
because the memory size of a class is usually not exactly a power of 2.

D also allows you to replace it's monitor with a custom monitor object  
(i.e. core.sync.Mutex) so you can have more control over the mutex, assign  
the same mutex to multiple objects, use conditions, etc.  It's much more  
flexible than Java or C# IMO.

-Steve