View mode: basic / threaded / horizontal-split · Log in · Help
March 01, 2007
Re: wait/notifyAll like in Java
> 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.
March 01, 2007
Re: wait/notifyAll like in Java
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
March 03, 2007
Re: wait/notifyAll like in Java
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.
March 03, 2007
Re: wait/notifyAll like in Java
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
March 15, 2007
Re: wait/notifyAll like in Java
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.
March 15, 2007
Re: wait/notifyAll like in Java
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.
March 15, 2007
Re: wait/notifyAll like in Java
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
March 15, 2007
Re: wait/notifyAll like in Java
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.
March 16, 2007
Re: wait/notifyAll like in Java
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()).
March 16, 2007
Re: wait/notifyAll like in Java
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
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home