wait/notifyAll like in Java

Sean Kelly sean at f4.ca
Fri Mar 16 08:10:40 PDT 2007


Juan Jose Comellas wrote:
> Sean Kelly wrote:
> 
>> Juan Jose Comellas wrote:
>>> [...]
>>> This functionality is already present in Tango SVN. I have added a
>>> function called _d_monitorget() to Tango's runtime library in
>>> lib/compiler/{dmd,gdc}/monitor.c. This function allows access to an
>>> Object's monitor. I have also modified the Mutex class in Tango to use
>>> its own monitor for locking and I have added a MutexProxy class to allow
>>> any object to have a mutex interface. With these modifications and the
>>> ones made to the tango.util.locks.Condition module it becomes trivial to
>>> have multiple condition variables associated to an Object's monitor and
>>> to implement the wanted Java-like functionality.
>> For what it's worth, this feature will not be present in the next
>> release of Tango so it can be evaluated a bit more carefully.  While I
>> like what it does, the way it is implemented would be the first
>> requirement of its kind (ie. telling the runtime /how/ something must be
>> implemented instead of /what/ must be implemented).  I want to take some
>> more time to weigh alternatives before adding this feature to an actual
>> release.  The optimal solution may simply be to add wait(), notify(),
>> and notifyAll() to Object like in Java.  I haven't had the time to think
>> it through yet.
>>
>>
>> Sean
> 
> The tight dependency between the runtime and the rest of the library is not
> something I wanted to introduce. The problem is that the other alternatives
> were much worse (at least to me). The options were: 
> 
> 1) implement the condition variable support in the runtime: this meant huge
> modifications to the runtime, especially because condition variables have
> to be emulated on Windows, as only Vista has native support for them. I
> discarded this option because I didn't want the Tango runtime to diverge so
> much from DMD.
> 
> 2) use an emulated condition variable on POSIX platforms: I discarded this
> one because the native implementation will probably be more efficient than
> the emulation in D and it would be silly not to use the features provided
> by each platform. In fact, I preferred option 1 to this one, but I had
> already discarded it for the reasons detailed above.
> 
> If diverging from the DMD runtime is not considered so much of a problem, we
> could create a portable set of functions in the runtime for condition
> variable support and use this from the Tango classes. We'd need something
> like this (in C code):
> 
> struct _d_cond_t;
> 
> _d_cond_t *_d_cond_create();
> void _d_cond_destroy(_d_cond_t *);
> void _d_cond_wait(_d_cond_t *, Object *);
> int _d_cond_timedwait(_d_cond_t *, Object *, long timeout); // timeout in ms
> void _d_cond_notify(_d_cond_t *);
> void _d_cond_notifyall(_d_cond_t *);
> 
> We would also need to implement some other functions to support the current
> functionality we have in the Mutex classes, such as timed waits on a
> monitor (pthread_mutex_timedlock()) and the ability to conditionally lock a
> mutex (i.e. the functionality of pthread_mutex_trylock()).

Yup, this whole thing is kind of a mess, which is why I wanted some time 
to weigh alternatives :-)  I'll admit I'd kind of like to provide some 
means of injecting a new mutex as the monitor as well, so named mutexes 
could be used for inter-process synchronization.  However, that still 
doesn't help the fact that Posix condvars need a pointer to an actual 
mutex to wait on rather than, say, calling lock() and unlock() on an 
interface.  I'm also not sure it would be acceptable to allow condvar 
integration only with monitors that have been overridden as described 
above, as this is something I'd prefer be a rare case rather than a 
common one.

My concern is that, as I said in a prior post, requiring the compiler 
runtime to return a pointer to a critical section (possibly overridden 
as a mutex I suppose) or to a mutex on Posix architectures imposes a 
requirement on /how/ the runtime is allowed to implement synchronized 
blocks.  I understand that this will be the most common means of doing 
so, but I am hesitant to actually require it.  So I'm kind of hoping 
that a bit of time will reveal an alternative way of hooking things 
together that is a bit more flexible.  It doesn't seem terribly likely, 
but I'd like that time all the same :-)


Sean



More information about the Digitalmars-d mailing list