Subj : Re: Challenge: Multithreading & Synchronization
To   : comp.programming.threads
From : doug
Date : Sun May 22 2005 12:33 am


"David Schwartz" <davids@webmaster.com> wrote in message 
news:d6nm22$i78$1@nntp.webmaster.com...
>
> "David Holmes" <dholmes@--remove-this-part-dltech.com.au> wrote in message 
> news:428d693c_2@news.melbourne.pipenetworks.com...
>
>> "doug" <noone@nowhere.co.uk> wrote in message
>> news:2SOie.16460$2k2.12826@fe1.news.blueyonder.co.uk...
>
>>> I don't want the 'solution' for your code, I want the
>>> pseudocode/implementation of a recursive lock that doesn't use memory
>>> barriers on recursive calls by the lock owner.  That's it.  That's all.
>>> Nothing else.
>
>> I don't want to get embroiled in the rest of this mess, but I'm not sure
>> what the problem is here.
>
>    The problem is that the owner field may be being modified while you 
> test it.
>

I know where you're coming from - that's where I came from too.  But some 
folk (Peter, Giancarlo) explained that *yes*, you might read the wrong 
value, but it doesn't matter.  You're guaranteed to get the answer to the 
question "do I own this lock" correct.

So I shall eat humble pie there.  Ta guys!  I'll check to see how we 
implement recursive sempahores.  To be honest, I can't think how we do 
that - we don't use them.  They're in the codebase, we just don't go near 
them.

OT - we played a gig tonight.  Question for extra points - how to 
synchronise the movements of a band!  Shit, sorry, i've had too much beer. 
later.

>> Accessing the owner field of a recursive lock, by the owner thread does 
>> not
>> require any memory barriers. Memory barriers are required to ensure
>> consistent memory views between different threads. When a thread becomes 
>> the
>> owner, or relinquishes ownership, then a memory barrier is involved. When 
>> a
>> thread is the owner then no memory barrier is needed. This assumes the 
>> owner
>> field is suitably aligned and can be read atomically. It also assumes 
>> that
>> no other thread maliciously stores the wrong thread-id in the owner 
>> field.
>
>    The idea that atomic reads and writes will work across multiple-CPUs is 
> a platform-specific optimization for C and C++.
>
>> It is not uncommon for Java monitor locks to be implemented this way. The
>> psuedocode is:
>>
>>    mon_enter() {
>>      if (mon.owner == currentThread())
>>          count++;
>>     else
>>         mon_enter_slow();  // blocks until monitor is free
>>
>>   mon_exit() {
>>      if (mon.owner == currentThread()) {
>>        if (--count == 0)
>>           mon_release_slow();
>>     }
>>     else throw an error
>>
>> There are no memory barriers on the fast-paths.
>
>    That's because Java is a single platform on which these 
> platform-specific optimizations are guaranteed to work. Try to create the 
> POSIX equivalent.
>
>    DS
>
>

.