> 2) Ben Hinkle has translated this package into D;

I found this lib, in an old version of mango.
In mango/locks/LockImpl.d the AbstractLock class implements the
wait/notify and the queue for waiting threads. That is probably on part
of what I need.

The other part is to bring together the D monitor with this lock.

Thanks for the hint.

Frank Benoit (keinfarbton) schrieb:
>>2) Ben Hinkle has translated this package into D;
> 
> 
> I found this lib, in an old version of mango.
> In mango/locks/LockImpl.d the AbstractLock class implements the
> wait/notify and the queue for waiting threads. That is probably on part
> of what I need.
> 
> The other part is to bring together the D monitor with this lock.
> 
> Thanks for the hint.
Okay, happy that I can help at least a bit. Bjoern

Subject: Monitor / *Scope(exit)*
Hi Frank,
at least this makes me think :

http://www.digitalmars.com/d/exception-safe.html

and especially :
void abc()
{
    Mutex m = new Mutex;

    lock(m);	// lock the mutex
    *scope(exit) unlock(m);	// unlock on leaving the scope *

    foo();	// do processing
}

Hope this is usefull, Bjoern

Frank Benoit (keinfarbton) schrieb:
>>2) Ben Hinkle has translated this package into D;
> 
> 
> I found this lib, in an old version of mango.
> In mango/locks/LockImpl.d the AbstractLock class implements the
> wait/notify and the queue for waiting threads. That is probably on part
> of what I need.
> 
> The other part is to bring together the D monitor with this lock.
> 
> Thanks for the hint.

Frank Benoit (keinfarbton) schrieb:
> 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?

Subject: Monitor / *Scope(exit)*
Hi Frank,
at least this makes me think :

http://www.digitalmars.com/d/exception-safe.html

especially :
void abc()
{
    Mutex m = new Mutex;

    lock(m);    // lock the mutex
    *scope(exit) unlock(m);    // unlock on leaving the scope *

    foo();    // do processing
}

and :
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Thread_synchronization_5382.html

Given:

synchronized(obj) { ... }

You can consider the opening brace of the synchronized block to be
equivalent to a mutex lock operation where obj is the mutex being
locked. *Exiting the scope* of a synchronized block by any means releases the lock.
Hope this is usefull , Bjoern

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?

We certainly need a way to access the monitor of an object, and hook it up with condition variables.

I would prefer to explicitly create condition variables (yes, more than one allowed) in an object, all tied to the object's monitor. The lack of multiple conditions per object is an issue in Java because you need complicated schemes involving child objects whenever you need multiple conditions.

Explicit creation of conditions is appropriate because most objects with a monitor don't need conditions.

This subject has been coming up on and off for years - can we please get something added to the runtime (if necessary) and to phobos and tango to implement conditions in a standard way? The lack of conditions tied to object monitors is a real pain.

Graham St Jack wrote:

> 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.
[...]
> 
> I would prefer to explicitly create condition variables (yes, more than one allowed) in an object, all tied to the object's monitor. The lack of multiple conditions per object is an issue in Java because you need complicated schemes involving child objects whenever you need multiple conditions.
> 
> Explicit creation of conditions is appropriate because most objects with a monitor don't need conditions.
> 
> This subject has been coming up on and off for years - can we please get something added to the runtime (if necessary) and to phobos and tango to implement conditions in a standard way? The lack of conditions tied to object monitors is a real pain.

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. In fact, Frank and I have already talked about this and we have come up with a JObject prototype that creates the necessary Condition on demand.

This functionality could easily be added to DMD/Phobos if Walter was willing to apply the attached patch to DMD's runtime in monitor.c.

Juan Jose Comellas wrote:
> Graham St Jack wrote:
> 
>> 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.
> [...]
>> I would prefer to explicitly create condition variables (yes, more than
>> one allowed) in an object, all tied to the object's monitor. The lack of
>> multiple conditions per object is an issue in Java because you need
>> complicated schemes involving child objects whenever you need multiple
>> conditions.
>>
>> Explicit creation of conditions is appropriate because most objects with
>> a monitor don't need conditions.
>>
>> This subject has been coming up on and off for years - can we please get
>> something added to the runtime (if necessary) and to phobos and tango to
>> implement conditions in a standard way? The lack of conditions tied to
>> object monitors is a real pain.
> 
> 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

Sean Kelly wrote:
> Juan Jose Comellas wrote:
>> Graham St Jack wrote:
>>
>>> 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.
>> [...]
>>> I would prefer to explicitly create condition variables (yes, more than one allowed) in an object, all tied to the object's monitor. The lack of multiple conditions per object is an issue in Java because you need complicated schemes involving child objects whenever you need multiple conditions.
>>>
>>> Explicit creation of conditions is appropriate because most objects with a monitor don't need conditions.
>>>
>>> This subject has been coming up on and off for years - can we please get something added to the runtime (if necessary) and to phobos and tango to implement conditions in a standard way? The lack of conditions tied to object monitors is a real pain.
>>
>> 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

This is excellent news!!!! Looking forward to this.

Take your time and get it right - but if you do go for the Java-like approach, please don't limit it to one condition per monitor.

Keep up the good work.

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

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