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?

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?

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

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) ?

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.

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

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

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

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?

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