Absolutely true.

I guesst what I am saying is that without the synchronize (obj) facility the
granularity of the
serialized code is at the method level rather than at the critical code level.

JH


In article <bl8si8$24ji$1@digitaldaemon.com>, Hauke Duden says...
>
>jhenzie@mac.com wrote:
>> Interesting,
>> 
>> Every object in D currently has a monitor, check out the memory  model excerpt
><snip>
>> The monitor already exists and provide the serialization primitive for
>> 
>> synchronized ( obj ) {}
>> 
>> While this might appear unnecessary given the ability to synchronize the encompassing method,
>
>I believe "synchronized" methods use that very same object mutex/monitor.
>
>I.e.
>
>synchronized void method()
>{
>	...code...
>}
>
>is just syntactic sugar for
>
>void method()
>{
>	synchronized(this)
>	{
>		...code...
>	}
>}
>
>So the object mutex is necessary if you want to have something like the synchronized statement.
>
>Hauke
>

jhenzie@mac.com wrote:
> Interesting,
> 
> Every object in D currently has a monitor, check out the memory  model excerpt

Yes, I know.  what I was driving at is that having synchronized methods isn't enough, and hence enter java's Object methods wait(), wait(x) and notify() which allow threads to communicate with each other meaningfully, not just keep out of each other's way.

What I am suggesting is an alternative to wait() and notify() that is pitched at a higher level, and is thus easier to use safely.

Of course I will be delighted when D is extended to allow inter-thread cooperation, whatever form it takes.

> 
> Object Model
> 
> 
> 
> An object consists of:
> 
> offset  contents
> ------  --------
> 0:      pointer to vtable
> 4:      monitor
> 8...    non-static members
> 
> 
> The monitor already exists and provide the serialization primitive for
> 
> synchronized ( obj ) {}
> 
> While this might appear unnecessary given the ability to synchronize the
> encompassing method, some classifications of applications desire very low thread contention and thus
> the granularity of the serialization can be significant thus may require a finer granularity than
> by method, the purist could argue that one should pull out the granualar critical section and place it
> in its own synchronized method but at the end of the day ( it gets dark ) , that also has
> cost associated with it.
> 
> Given that desire to provide finer granularity, it would be necessary to support
> the monitor per object semantics that are already in place and thus the ability to ceed ones
> lock on the monitor within the scope of the critical section, thus Object.wait(), Object.wait(x);
> 
> It is my belief that this is the simplest, most supportable mechanism for
> multithreading.  Those of us who have had the pleasure, and pain, of using Java can attest to how flexible
> this arrangement is.
> 
> Of course I am also in favour of providing a library as complete as pthreads for
> those for which the simple solution does not suffice, but to be honest I would be very surprised if
> it was often used.
> 
> I have yet to fix the linux deadlock problem in the existing implementation,
> windows fix has been posted to this forum earlier, just a matter of finding the time to sit down at a
> linux box,  But once done I would very much enjoy collaborating on this, and I am fairly sure Walter
> will be thrilled.
> 
> I think its a testament to D that the posts on this forum are more often than
> not intelligent, rational and balanced.  Visit the javalobby to see what can happen <smile/>
> 
> Justin
> 
> 
> 
> 
> In article <bl89h4$15vl$1@digitaldaemon.com>, Graham StJack says...
> 
>>I would like to see something pitched at a higher level - the low-level
>>stuff is just too easy to get wrong.  Something along the lines of the
>>following code fragment, which is easy to get right, and fairly easy for
>>the compiler to do, might be worth discussing.  I prefer extending the
>>language instead of adding new classes because it increases the options
>>for both compile-time and run-time error checking.
>>
>>class Queue {
>>  int itemCount = 0;
>>  barrier bit empty = true;
>>
>>  public synchronized void remove() barrier empty {
>>    itemCount--;
>>    empty = (itemCount == 0);
>>  }
>>
>>  public synchronized void add() {
>>    itemCount++;
>>    empty = false;
>>  }
>>}
>>
>>The compiler would:
>>* Be extended to treat barrier as a keyword.
>>* Insist on exactly one call that uses a barrier condition for each
>>  declared barrier.  In the example, it is remove().
>>* Allow more than one barrier per class.
>>* For each barrier instance, set up a list of blocked threads.
>>* Generate extra code for remove() that, if the barrier is true,
>>  adds the thread to the back of the barrier's list and suspends
>>  the thread.
>>* Generate extra code that fires whenever the barrier becomes
>>  false (ie changes from true to false), that resumes the front thread
>>  on the barrier's list.
>>
>>
>>I am assuming here that suspending and resuming threads is a cheap operation.
>>A similar arrangement could be achieved using pthreads, but I don't know how
>>to use them directly - I have used Ada protected objects, which do it for me.
>>
>>
>>
>>Mike Wynn wrote:
>>
>>>jhenzie@mac.com wrote:
>>>
>>>
>>>>I have been giving this some thought over the past week.  I think D should offer
>>>>a simple mechanism for threading using a similar appriach as Java.
>>>>
>>>>That being
>>>>synchronized ( obj ) {
>>>>
>>>>obj.wait();
>>>>obj.wait(uint milliseconds);
>>>>obj.tryWait();
>>>>
>>>>obj.notify();1
>>>>obj.notifyAll();
>>>>}
>>>>
>>>
>>>I agree IF obj is either a monitor or an object marked as synchronizable.
>>>one problem with the Java approach (where all object have an associated monitor) is that every object potentially requires a monitor, this either causes a big resource overhead that is not used, or lots of work for the compiler writer/library writer to deal with the cases when a monitor is not used or only used by one thread.
>>>
>>>I do not belive that alloing any object to be "synchronized" makes code any more thread safe than only allowing "synchonisation" on specified objects.
>>>
>>>as D allows lower level programming than Java I think the sync primatives should allow a little more programmer control than the Java approach does.
>>>
>>>
>>>I'm not sure if "wait/notify" should be part of a synchronised obj,
>>>
>>>interface Syncronizable {
>>>    /* get monitor (blocks unless you already own the monitor) */
>>>    void enter();
>>>    /* get monitor (blocks unless you already own the monitor)
>>>     * will only block for timeout ms, then returns false */
>>>    bit enter( int timeout );
>>>    /* try to get monitor returns false if already locked
>>>     * by another thread (never blocks might task switch) */
>>>    bit tryEnter();
>>>    /* leave monitor (one level) */
>>>    void leave() throws UnownedError;
>>>    /* release all levels */
>>>    void release();
>>>}
>>>
>>>interface Waitable {
>>>    void wait();
>>>    bit wait( int timeout ); // true if notified
>>>    void notify(); // notify one waiter (non blocking)
>>>    void notifyAll(); // notify all waiters (non blocking)
>>>    void notifyExchange(); // notify and switch to waiter
>>>}
>>>
>>>interface SyncWaiter : Waitable, Syncnizable {
>>>    // here wait/notify calls also call lock thus
>>>    // notify calls are only non blocking if you have the lock.
>>>
>>>    // so this may be required.
>>>    bit tryNotify(); // notify if unlocked
>>>}
>>>
>>>synchronized blocks/methods can only be used with objects that implment Syncronizable (implemented internally).
>>>
>>>
>>
> 
> 

Graham,

Totally with you.

IMHO the wait, notify mechanism is pretty easy to use, and, given the ownership sematics, is very safe, but I am all for providing a mechanism that communicates the intent.

JH

In article <blact3$16hj$1@digitaldaemon.com>, Graham StJack says...
>
>jhenzie@mac.com wrote:
>> Interesting,
>> 
>> Every object in D currently has a monitor, check out the memory  model excerpt
>
>Yes, I know.  what I was driving at is that having synchronized methods isn't enough, and hence enter java's Object methods wait(), wait(x) and notify() which allow threads to communicate with each other meaningfully, not just keep out of each other's way.
>
>What I am suggesting is an alternative to wait() and notify() that is pitched at a higher level, and is thus easier to use safely.
>
>Of course I will be delighted when D is extended to allow inter-thread cooperation, whatever form it takes.
>
>> 
>> Object Model
>> 
>> 
>> 
>> An object consists of:
>> 
>> offset  contents
>> ------  --------
>> 0:      pointer to vtable
>> 4:      monitor
>> 8...    non-static members
>> 
>> 
>> The monitor already exists and provide the serialization primitive for
>> 
>> synchronized ( obj ) {}
>> 
>> While this might appear unnecessary given the ability to synchronize the
>> encompassing method,
>> some classifications of applications desire very low thread contention and thus
>> the granularity of
>> the serialization can be significant thus may require a finer granularity than
>> by method, the purist
>> could argue that one should pull out the granualar critical section and place it
>> in its own
>> synchronized method but at the end of the day ( it gets dark ) , that also has
>> cost associated with
>> it.
>> 
>> Given that desire to provide finer granularity, it would be necessary to support
>> the monitor per
>> object semantics that are already in place and thus the ability to ceed ones
>> lock on the monitor
>> within the scope of the critical section, thus Object.wait(), Object.wait(x);
>> 
>> It is my belief that this is the simplest, most supportable mechanism for
>> multithreading.  Those of
>> us who have had the pleasure, and pain, of using Java can attest to how flexible
>> this arrangement
>> is.
>> 
>> Of course I am also in favour of providing a library as complete as pthreads for
>> those for which the
>> simple solution does not suffice, but to be honest I would be very surprised if
>> it was often used.
>> 
>> I have yet to fix the linux deadlock problem in the existing implementation,
>> windows fix has been
>> posted to this forum earlier, just a matter of finding the time to sit down at a
>> linux box,  But once
>> done I would very much enjoy collaborating on this, and I am fairly sure Walter
>> will be thrilled.
>> 
>> I think its a testament to D that the posts on this forum are more often than
>> not intelligent,
>> rational and balanced.  Visit the javalobby to see what can happen <smile/>
>> 
>> Justin
>> 
>> 
>> 
>> 
>> In article <bl89h4$15vl$1@digitaldaemon.com>, Graham StJack says...
>> 
>>>I would like to see something pitched at a higher level - the low-level stuff is just too easy to get wrong.  Something along the lines of the following code fragment, which is easy to get right, and fairly easy for the compiler to do, might be worth discussing.  I prefer extending the language instead of adding new classes because it increases the options for both compile-time and run-time error checking.
>>>
>>>class Queue {
>>>  int itemCount = 0;
>>>  barrier bit empty = true;
>>>
>>>  public synchronized void remove() barrier empty {
>>>    itemCount--;
>>>    empty = (itemCount == 0);
>>>  }
>>>
>>>  public synchronized void add() {
>>>    itemCount++;
>>>    empty = false;
>>>  }
>>>}
>>>
>>>The compiler would:
>>>* Be extended to treat barrier as a keyword.
>>>* Insist on exactly one call that uses a barrier condition for each
>>>  declared barrier.  In the example, it is remove().
>>>* Allow more than one barrier per class.
>>>* For each barrier instance, set up a list of blocked threads.
>>>* Generate extra code for remove() that, if the barrier is true,
>>>  adds the thread to the back of the barrier's list and suspends
>>>  the thread.
>>>* Generate extra code that fires whenever the barrier becomes
>>>  false (ie changes from true to false), that resumes the front thread
>>>  on the barrier's list.
>>>
>>>
>>>I am assuming here that suspending and resuming threads is a cheap operation. A similar arrangement could be achieved using pthreads, but I don't know how to use them directly - I have used Ada protected objects, which do it for me.
>>>
>>>
>>>
>>>Mike Wynn wrote:
>>>
>>>>jhenzie@mac.com wrote:
>>>>
>>>>
>>>>>I have been giving this some thought over the past week.  I think D
>>>>>should offer
>>>>>a simple mechanism for threading using a similar appriach as Java.
>>>>>
>>>>>That being
>>>>>synchronized ( obj ) {
>>>>>
>>>>>obj.wait();
>>>>>obj.wait(uint milliseconds);
>>>>>obj.tryWait();
>>>>>
>>>>>obj.notify();1
>>>>>obj.notifyAll();
>>>>>}
>>>>>
>>>>
>>>>I agree IF obj is either a monitor or an object marked as synchronizable. one problem with the Java approach (where all object have an associated monitor) is that every object potentially requires a monitor, this either causes a big resource overhead that is not used, or lots of work for the compiler writer/library writer to deal with the cases when a monitor is not used or only used by one thread.
>>>>
>>>>I do not belive that alloing any object to be "synchronized" makes code any more thread safe than only allowing "synchonisation" on specified objects.
>>>>
>>>>as D allows lower level programming than Java I think the sync primatives should allow a little more programmer control than the Java approach does.
>>>>
>>>>
>>>>I'm not sure if "wait/notify" should be part of a synchronised obj,
>>>>
>>>>interface Syncronizable {
>>>>    /* get monitor (blocks unless you already own the monitor) */
>>>>    void enter();
>>>>    /* get monitor (blocks unless you already own the monitor)
>>>>     * will only block for timeout ms, then returns false */
>>>>    bit enter( int timeout );
>>>>    /* try to get monitor returns false if already locked
>>>>     * by another thread (never blocks might task switch) */
>>>>    bit tryEnter();
>>>>    /* leave monitor (one level) */
>>>>    void leave() throws UnownedError;
>>>>    /* release all levels */
>>>>    void release();
>>>>}
>>>>
>>>>interface Waitable {
>>>>    void wait();
>>>>    bit wait( int timeout ); // true if notified
>>>>    void notify(); // notify one waiter (non blocking)
>>>>    void notifyAll(); // notify all waiters (non blocking)
>>>>    void notifyExchange(); // notify and switch to waiter
>>>>}
>>>>
>>>>interface SyncWaiter : Waitable, Syncnizable {
>>>>    // here wait/notify calls also call lock thus
>>>>    // notify calls are only non blocking if you have the lock.
>>>>
>>>>    // so this may be required.
>>>>    bit tryNotify(); // notify if unlocked
>>>>}
>>>>
>>>>synchronized blocks/methods can only be used with objects that implment Syncronizable (implemented internally).
>>>>
>>>>
>>>
>> 
>> 
>