swarm-modeling
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ||ism


From: Scott Christley
Subject: Re: ||ism
Date: Fri, 9 May 1997 13:38:52 -0700

Interesting!  That "synchronized" keyword sounds like a possible good
enhancement to the ObjC language.  A flag could be put into the selector
structure which indicates if such synchronization should occur; that means
only one additional comparison needs to be added to the message lookup routine.

Hmm, it requires some thought though, because if you are going to spend the
time to figure out which methods require "synchronized" or not, then you
might as well just add another instance variable, which is a mutex, and at
the code to lock/unlock within the method.

Scott

At 07:11 PM 5/8/97 -0700, manor wrote:
>
>> Is this thread-safety something that completely surrounds the object's
>> methods; meaning if one thread calls a method on the object, that object
>> is locked and no other thread can call any method on that object?
>
>Almost...
>
>> I can see how that might be used as a large-grain mechanism;
>> it's expensive though because it requires maintaining a recursive
>> mutex for every instance in the system, plus checking operations
>> with each method call.
>
>Which is why the programmer specifies thread-saftey on a per_method basis:
>
>class thing {
>
>  private int height_ ;
>
>  int getHeight(){
>    return height_ ;
>  }
>
>  synchronized void changeHeight(int newHeight){
>    height_ = newHeight ;
>  }
>}
>
>The mutex is there per instance (only one per instance, btw, which seems to
>address the common case), but is only tested per call to changeHeight().
>
>Obviously, no mutex is generated by the compiler if the synchronized keyword
>is missing from all the methods.
>
>Oh, if you want a per-class lock, you can specify 'synchronized' on a 'static'
>(class) method.
>
>Also, there is language support for a monitor-queue per lock (so, the locks
>are potentially full-blown monitors which support a wait() and notify()
>method):
>
>class HoldEmAll {
>
>  synchronized void willBlock(){
>
>    // All Threads Do This (In Turn)
>
>    wait() ;
>
>    // After Waiting, All Threads Do This, (In Turn - Mutex is
>    // still maintained)!!!
>
>  }
>
>  synchronized void releaseThemAll(){
>    notifyAll() ;
>  }
>}
>
>[All the threads which call HoldEmAll will end up on an internal wait queue
>and will lose the lock they got when calling willBlock() (they don't lose
>any other locks), then if some other thread calls releaseThemAll(), there
>is a race to re-capture the lock and continue the method right after the
>wait()].
>
>One of the reasons I am optimistic about threads/SMP for ||ism is that many
>programmers are now being introduced to this approach at the language level
>when they learn Java. I guess the same effect is achieved by wrapping up
>the platform dependent thread-crud into ObjC (pthread vs. lwp etc.).
>What is the API? Is this a port of a similar mechanism from Next?
>
>Manor.
>
>
>                  ==================================
>   Swarm-Modelling is for discussion of Simulation and Modelling techniques
>   esp. using Swarm.  For list administration needs (esp. [un]subscribing),
>   please send a message to <address@hidden> with "help" in the
>   body of the message.
>                  ==================================
>



                  ==================================
   Swarm-Modelling is for discussion of Simulation and Modelling techniques
   esp. using Swarm.  For list administration needs (esp. [un]subscribing),
   please send a message to <address@hidden> with "help" in the
   body of the message.
                  ==================================


reply via email to

[Prev in Thread] Current Thread [Next in Thread]