Subj : Re: Challenge: Multithreading & Synchronization To : comp.programming.threads From : David Schwartz Date : Sat May 21 2005 10:02 am "David Holmes" wrote in message news:428d693c_2@news.melbourne.pipenetworks.com... > "doug" 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. > 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 .