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.
