wait/notifyAll like in Java

Juan Jose Comellas jcomellas at gmail.com
Fri Mar 16 06:07:06 PDT 2007


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()).




More information about the Digitalmars-d mailing list