Subj : Re: Challenge: Multithreading & Synchronization
To   : comp.programming.threads
From : David Holmes
Date : Fri May 20 2005 03:37 pm

"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.

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.

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.

David Holmes

.