www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - wait/notifyAll like in Java

reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
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?
Feb 28 2007
next sibling parent reply Juan Jose Comellas <jcomellas gmail.com> writes:
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?

Mar 01 2007
next sibling parent Sean Kelly <sean f4.ca> writes:
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 *);

I've been thinking about providing hooks for manipulating monitors in Tango, though I was thinking more of doing so to allow them to be used for process synchronization and the like. The goal being to allow objects to be shared between processes without placing any restrictions on how they can be used. This is more of a long-term project, but I brought it up because it may apply here.
 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?

I'd like to know this as well. Sean
Mar 01 2007
prev sibling parent reply kris <foo bar.com> writes:
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 :) 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) ?
Mar 01 2007
parent Juan Jose Comellas <jcomellas gmail.com> writes:
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.
Mar 01 2007
prev sibling next sibling parent reply BLS <Killing_Zoe web.de> writes:
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?

Hi Frank, probabely this hint is simply shi* but I suggest to have a look on Dough Leas concurrent library at : http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html The package mainly consists of implementations of a few interfaces: * Sync -- locks, conditions * Channel -- queues, buffers * Barrier -- multi-party synchronization * SynchronizedVariable -- atomic ints, refs etc * Executor -- replacements for direct use of Thread wait() is AFAIK implemented try { while (true) lock.wait(); } catch (InterruptedException e) { } HTH and Sorry in case that I miss something. ;-) Bjoern
Mar 01 2007
parent reply BLS <Killing_Zoe web.de> writes:
BLS schrieb:
 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?

Hi Frank, probabely this hint is simply shi* but I suggest to have a look on Dough Leas concurrent library at : http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html The package mainly consists of implementations of a few interfaces: * Sync -- locks, conditions * Channel -- queues, buffers * Barrier -- multi-party synchronization * SynchronizedVariable -- atomic ints, refs etc * Executor -- replacements for direct use of Thread wait() is AFAIK implemented try { while (true) lock.wait(); } catch (InterruptedException e) { } HTH and Sorry in case that I miss something. ;-) Bjoern

Some additional info from *sync.java* * Main interface for locks, gates, and conditions. * Sync objects isolate waiting and notification for particular * logical states, resource availability, events, and the like that are * shared across multiple threads. Use of Syncs sometimes * (but by no means always) adds flexibility and efficiency * compared to the use of plain java monitor methods * and locking, and are sometimes (but by no means always) * simpler to program with. Regards, Bjoern
Mar 01 2007
next sibling parent reply BLS <Killing_Zoe web.de> writes:
BLS schrieb:
 BLS schrieb:
 
 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?

Hi Frank, probabely this hint is simply shi* but I suggest to have a look on Dough Leas concurrent library at : http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html The package mainly consists of implementations of a few interfaces: * Sync -- locks, conditions * Channel -- queues, buffers * Barrier -- multi-party synchronization * SynchronizedVariable -- atomic ints, refs etc * Executor -- replacements for direct use of Thread wait() is AFAIK implemented try { while (true) lock.wait(); } catch (InterruptedException e) { } HTH and Sorry in case that I miss something. ;-) Bjoern

Some additional info from *sync.java* * Main interface for locks, gates, and conditions. * Sync objects isolate waiting and notification for particular * logical states, resource availability, events, and the like that are * shared across multiple threads. Use of Syncs sometimes * (but by no means always) adds flexibility and efficiency * compared to the use of plain java monitor methods * and locking, and are sometimes (but by no means always) * simpler to program with. Regards, Bjoern

1) The java package is public domain, 2) Ben Hinkle has translated this package into D; ........... Bjoern exit
Mar 01 2007
parent reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
 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.
Mar 01 2007
next sibling parent BLS <Killing_Zoe web.de> writes:
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.

Mar 01 2007
prev sibling parent BLS <Killing_Zoe web.de> writes:
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.

Mar 03 2007
prev sibling parent reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
Thanks for the pointer.

As I understand the source of this lib, they build advanced behavior on
top of the Object.wait/notify methods.

So this lib cannot help in implementing those methods?
Did I miss the point?
Mar 01 2007
parent BLS <Killing_Zoe web.de> writes:
Frank Benoit (keinfarbton) schrieb:
 Thanks for the pointer.
 
 As I understand the source of this lib, they build advanced behavior on
 top of the Object.wait/notify methods.
 
 So this lib cannot help in implementing those methods?
 Did I miss the point?

Bjoern
Mar 01 2007
prev sibling next sibling parent BLS <Killing_Zoe web.de> writes:
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
Mar 03 2007
prev sibling parent reply Graham St Jack <grahams acres.com.au> writes:
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.
Mar 14 2007
parent reply Juan Jose Comellas <jcomellas gmail.com> writes:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8Bit

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.
Mar 15 2007
parent reply Sean Kelly <sean f4.ca> writes:
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
Mar 15 2007
next sibling parent Graham St Jack <grahams acres.com.au> writes:
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.
Mar 15 2007
prev sibling parent reply Juan Jose Comellas <jcomellas gmail.com> writes:
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()).
Mar 16 2007
parent Sean Kelly <sean f4.ca> writes:
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.

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
Mar 16 2007