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


Hell, I am out of order.
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.


Okay, happy that I can help at least a bit. Bjoern
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?


IMO   Instead of .... We Have to investigate
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:
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.


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