Proposal: adding condition variable to object monitors

[Sean Kelly]

Jeremie Pelletier wrote:
> Sean Kelly Wrote:
> 
>> They're already in druntime for D2, though they haven't been distributed 
>> yet (dunno why).  And they can act like they're built in:
>>
>> class C
>> {
>>      Mutex     m;
>>      Condition c;
>>
>>      this()
>>      {
>>          // make m this object's monitor
>>          m = new Mutex( this );
>>          c = new Condition( m );
>>      }
>>
>>      synchronized void foo()
>>      {
>>          // m is locked
>>          c.notify();
>>      }
>> }
> 
>> Oh, on Windows, condition variables were added in Vista, so that code 
>> won't work on XP or earlier.
> 
> Hmm, I wasn't aware of that, it's been a while since I last checked the druntime project to tell the truth (my runtime has been running the full set of D features for quite some time now). But my proposal was to make both mutexes and conditions completely transparent, only exposing wait, notify and notifyall through Object, as they are implemented directly in the object's hidden monitor.

I considered this as well, but it imposes limitations that aren't 
present with the current approach.  It's possible to have more than one 
condition associated with a particular mutex, for example, and to plug 
in a shared mutex for interprocess synchronization using 'synchronized'.

> The way druntime does it from your example is explicit: both the mutex and condition have to be manually declared and set, which may be because automatic object monitors are still allocated through alloc/free. Moreover, if only a handful of instanciated objects uses the condition, there's wasted memory for the condition.

They could always be added to a project-specific base class.  The 
additional memory allocations are still an issue I suppose, but even 
normal monitors are allocated on the heap, even if it is via malloc.

> I heavily modified my runtime to allow most of it to completely remove it's usage of the C alloc and free routines (i think only memory pool structs still use these), so I implemented my condition variable directly into the monitor struct, the monitor is already created lazily for the object and so is the condition for the monitor.

So the monitor struct is still dynamically allocated, correct?

> And I am aware conditions were added in vista, the file which runs a check at startup for vista. I just haven't coded a fallback for xp and down yet ;)

Just wanted to make sure you were aware of that limitation :-)  Creating 
a correct condvar implementation is non-trivial, so it's worth being 
aware of.