[M3devel] lock performance, random thoughts

[Jay K]

 > pthread_mutex_lock/unlock does not imply a kernel call. !
 > pthreads can synchronize in usermode just as well (or only almost as well?) as Tony's design.
 > Only upon contention is a kernel call needed, in both.


 

Without the extra biasing and avoiding atomic ops, I believe it goes something like:

 

 

typedef struct recursive_exclusive_lock_t {
  long owner;
  long count = -1; /* -1 for 386 compat, else 0 is ok and adjust below */
  void* kernel object; /* may or may not initialize this up front or on demand, if on demand, beware low resources in the middle of locking */
} recursive_exclusive_lock_t;

 

 

recursive_exclusive_lock:
  while (1)
    new_count = InterlockedIncrement(count);
    if new_count == 0 /* 1 for 486+, allows for zero initialization */ 
      owner = current thread
      return
    if new_count > 0 /* 1 for 486+, allows for zero initialization */ 
      if owner == current thread id
         return
    InterlockedDecrement(count);
    maybe an extra brief spin here on MP systems, in case contention is very short
    wait on kernel object

 

 

recursive_exclusive_unlock:
  assert(owner == current thread id)
  InterlockedDecrement(count);

 

 

typedef struct exclusive_lock_t {
  long owner;
  void* kernel object;
} exclusive_lock_t;


 

exclusive_lock:
  while (1)
    if interlocked compare exchange(owner, 0, current thread id) == 0
      return
    maybe an extra brief spin here on MP systems, in case contention is very short 
    wait on kernel object


 

exclusive_unlock:
  assert(owner == current thread id)
  owner = 0

 

 

The first resembles Win32 critical sections.
The second is what the Sun Java VM does on Win32.

kernel_lock is a Win32 event.

  I had that in Modula-3 but only briefly.


 

No kernel call in uncontended cases.
But still atomics.

 

 - Jay





 


From: jay.krell at cornell.edu
To: dragisha at m3w.org; hosking at cs.purdue.edu
Date: Tue, 6 Apr 2010 00:13:07 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] lock performance, random thoughts



pthread_mutex_lock/unlock does not imply a kernel call. !
pthreads can synchronize in usermode just as well (or only almost as well?) as Tony's design.
Only upon contention is a kernel call needed, in both.
 
 
That's not to say that everyone implements this well.
Linux does.
Win32 does.
The others I don't know.
 
 
Also Tony avoids even atomic operations often.
I'm not sure how others compare there.
I'm just referring to kernel/syscalls.
Are they really so terrible?
 
 
 - Jay

 
> From: dragisha at m3w.org
> To: hosking at cs.purdue.edu
> Date: Tue, 6 Apr 2010 01:57:07 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] lock performance, random thoughts
> 
> I've used Java for one project, "GUI" app frontend for mobile phones...
> What I saw first was their mixup of mutex/condition/cheese in single
> root object... But, ok... offtopic there :)
> 
> What I think is important about whole idea is it's simplicity and
> (almost) obvious efficiency. It also needs nothing fancy (not today, at
> least) and nothing maybe-it-works to implement. Nothing comparable to
> early implementations of kernel space threading/thread suspending for
> gc/...
> 
> Any takers? :)
> 
> 
> On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote:
> > Yes, that's pretty much what modern Java implementations do.
> > 
> > 
> -- 
> Dragiša Durić <dragisha at m3w.org>
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100406/865c4799/attachment-0002.html>