Re: thread question

[Willem Rein Oudshoorn]

Aurelien <aurelien@fractals.be> writes:

> generally, I know how to handle code like this:
> 
> synchronized void doSomething () {
>    // do something
> }
> 
> -> I translate that into:
> 
> - (void) doSomething
> {
>    NS(Recursive)Lock *aLock;
>    aLock = [[NS(Recursive)Lock alloc] init];
>    [aLock lock];
>    // do something
>    [aLock unlock];
> }

Ok, you are almost right.  However the lock should not be
a local variable. And actually the best equivalent is 
an NSRecursiveLock.

Now about wait and notify.  [DISCLAIMER, I do not really 
understand Java threading, it is just too cumbersome]
Actually you want probably to read an answer from someone
who knows Java better than I do.

Ok, here it goes.  Lets start with what happens when 
you enter a syncrhonized block:

        synchronized (anObject) {
                code;
        }

when such a block is entered by thread A
the monitor associated with `anObject' is grabbed.  
This corresponds to taking the lock in objectiveC.

[If anObject is not specified it is implicitly replaced
by `this']

If another thread tries to access a block of code
that is guarded by the monitor [synchronized (anObject) {...}]
it will block because the monitor is already taken by thread A.
Just as trying to get the lock in ObjectiveC will fail
if it as already in the possesion of another thread.                      

Suppose now that Thread A encounters a 
        wait 
call.
What happens is that the wait call will do the following:

        - Give up the monitor it, at this moment, posesses.
        - wait until it is notified by the monitor.

At this moment, thread B, which was blocking, will grab
the just released monitor and enter the synchronized block.
So now thread B possesses the lock.
Now after a while thread B encounters a 
        notify

Then the following happens.
        - It will notify thread A and transfer the monitor
                back to Thread 
        - Thread A was still waiting. Now it is notified,
                grabs the monitor and continue
        - Thread B will now block until it can reacquire the 
                monitor.

So that is basically it.
Typical use is that Thread A creates a new thread and wants
to wait until thread B has done some initializiation.  This will 
look something like this, in pseudo code:

void main_run_in_thread_A
{
        synhronized (XXXXX)
        {
                create_thread_and_run_method (method_for_B);
        
                wait;
        }
        continue with thread A, 
}

void method_for_B
{
        do all my initialization;
        
        synchronized (XXXXX)
        {
                notify;
        }
        continue with thread B
}


Please, Java experts (Nicola ?), shoot holes in this.  It just from the top
of my head and as I said I do not really have a lot 
of experience with this. 

Note, in GNUstep you should use NSConditionLock for this.  Personnally
I find it much easier to use.  And NSConditionLocks are predictable.
> 
> Only, I don't see an obvious way to emulate this in objc.
>
Look at the NSConditionLock.  And I do not think it is worth emulating,
just figure out what kind of synchronization is needed between the different
threads and redesign the synchronization.
 
> But I'm sure this has certainly be addressed a 1000 times.

I am not so sure :-)

Wim Oudshoorn.