wait/notifyAll like in Java

[Juan Jose Comellas]

kris wrote:

> Juan Jose Comellas wrote:
>> To achieve what you mention we need to combine D's Object monitor with a
>> condition variable. We can create this in Tango based on the
>> tango.util.locks.Condition class, but we'd need access to each Object's
>> hidden monitor member variable. There is an Object struct in the
>> src/phobos/internal/mars.h file present in DMD's distribution that holds
>> the pointer to the monitor (which is implemented as a pthread_mutex_t on
>> Linux and a CRITICAL_SECTION on Windows) and the monitor functions are in
>> the monitor.c file in the same directory. If we could add a function like
>> the following one to this file we'd have all we need:
>> 
>> void *_d_monitorget(Object *);
>> 
>> Another possibility would be to add this behavior directly to DMD and
>> have it available everywhere. It would mean making each Object that is
>> synchronized a little bit more heavyweight. On Linux we would have to add
>> a pthread_cond_t to the monitor and on Windows we'd have to emulate the
>> condition variable with an extra mutex, semaphore and event.
>> 
>> Which option seems more attractive to everybody?
>> 
>> 
>> Frank Benoit (keinfarbton) wrote:
>> 
>> 
>>>While porting java stuff, i come to this:
>>>
>>>How can I implement a JObject class as a base of all the ported classes
>>>to have wait/notify/notifyAll with the behaviour like in Java.
>>>
>>>http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html
>>>
>>>The "synchronized" of D objects, already uses some monitor.
>>>Is it possible to access and use it for such an implementation?
>> 
>> 
> 
> 
> My concern would be twofold:
> 
> 1) As I understand it, D adds monitors only where it is required --
> those scenarios where a synch is applied? If it were to create a monitor
> for each and every object created, I think there would be a notable
> resource issue :)

I was not planning on forcing the instantiation of the monitor all the time.
Condition variables need the associated mutex to be locked before any
action is performed on them, and D's Object monitor is created on demand
whenever a synchronized block is entered (i.e. the monitor mutex is
locked). The condition variable could be created at the same time the
monitor is created, so the overhead would only be present on objects that
are used for synchronized blocks. In the cases where the monitor has not
been created (because of a programmer error), we could simply throw an
exception.

> 
> 2) There some concern over the sharing of such instances. What does it
> mean to synchronize on a D monitor, whilst it is also being used for the
> above purposes (as a condition, for example) ?

I'm not sure I understand what you're asking. Condition variables are
designed to be shared and are perfectly thread-safe, so the ability to
share objects among threads would not be hindered in any way by this. This
is exactly the way objects in Java work.