View mode: basic / threaded / horizontal-split · Log in · Help
February 28, 2007
wait/notifyAll like in Java
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?
March 01, 2007
Re: wait/notifyAll like in Java
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?
March 01, 2007
Re: wait/notifyAll like in Java
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
March 01, 2007
Re: wait/notifyAll like in Java
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) ?
March 01, 2007
Re: wait/notifyAll like in Java
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.
March 01, 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?

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
March 01, 2007
Re: wait/notifyAll like in Java
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
March 01, 2007
Re: wait/notifyAll like in Java
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
March 01, 2007
Re: wait/notifyAll like in Java
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?
March 01, 2007
Re: wait/notifyAll like in Java
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
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home