<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
> pthread_mutex_lock/unlock does not imply a kernel call. !<BR> > pthreads can synchronize in usermode just as well (or only almost as well?) as Tony's design.<BR> > Only upon contention is a kernel call needed, in both.<BR><BR>
<BR>
Without the extra biasing and avoiding atomic ops, I believe it goes something like:<BR>
<BR>
<BR>
typedef struct recursive_exclusive_lock_t {<BR> long owner;<BR> long count = -1; /* -1 for 386 compat, else 0 is ok and adjust below */<BR> 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 */<BR>} recursive_exclusive_lock_t;<BR>
<BR>
<BR>
recursive_exclusive_lock:<BR> while (1)<BR> new_count = InterlockedIncrement(count);<BR> if new_count == 0 /* 1 for 486+, allows for zero initialization */ <BR> owner = current thread<BR> return<BR> if new_count > 0 /* 1 for 486+, allows for zero initialization */ <BR> if owner == current thread id<BR> return<BR> InterlockedDecrement(count);<BR> maybe an extra brief spin here on MP systems, in case contention is very short<BR> wait on kernel object<BR>
<BR>
<BR>
recursive_exclusive_unlock:<BR> assert(owner == current thread id)<BR> InterlockedDecrement(count);<BR>
<BR>
<BR>
typedef struct exclusive_lock_t {<BR> long owner;<BR> void* kernel object;<BR>} exclusive_lock_t;<BR>
<BR> <BR>
exclusive_lock:<BR> while (1)<BR> if interlocked compare exchange(owner, 0, current thread id) == 0<BR> return<BR> maybe an extra brief spin here on MP systems, in case contention is very short <BR> wait on kernel object<BR>
<BR> <BR>
exclusive_unlock:<BR> assert(owner == current thread id)<BR> owner = 0<BR>
<BR>
<BR>
The first resembles Win32 critical sections.<BR>The second is what the Sun Java VM does on Win32.<BR>
kernel_lock is a Win32 event.<BR>
I had that in Modula-3 but only briefly.<BR><BR>
<BR>
No kernel call in uncontended cases.<BR>But still atomics.<BR>
<BR>
- Jay<BR><BR><BR><BR><BR><BR> <BR>
<HR id=stopSpelling>
From: jay.krell@cornell.edu<BR>To: dragisha@m3w.org; hosking@cs.purdue.edu<BR>Date: Tue, 6 Apr 2010 00:13:07 +0000<BR>CC: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] lock performance, random thoughts<BR><BR>
<STYLE>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
pthread_mutex_lock/unlock does not imply a kernel call. !<BR>pthreads can synchronize in usermode just as well (or only almost as well?) as Tony's design.<BR>Only upon contention is a kernel call needed, in both.<BR> <BR> <BR>That's not to say that everyone implements this well.<BR>Linux does.<BR>Win32 does.<BR>The others I don't know.<BR> <BR> <BR>Also Tony avoids even atomic operations often.<BR>I'm not sure how others compare there.<BR>I'm just referring to kernel/syscalls.<BR>Are they really so terrible?<BR> <BR> <BR> - Jay<BR><BR> <BR>> From: dragisha@m3w.org<BR>> To: hosking@cs.purdue.edu<BR>> Date: Tue, 6 Apr 2010 01:57:07 +0200<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] lock performance, random thoughts<BR>> <BR>> I've used Java for one project, "GUI" app frontend for mobile phones...<BR>> What I saw first was their mixup of mutex/condition/cheese in single<BR>> root object... But, ok... offtopic there :)<BR>> <BR>> What I think is important about whole idea is it's simplicity and<BR>> (almost) obvious efficiency. It also needs nothing fancy (not today, at<BR>> least) and nothing maybe-it-works to implement. Nothing comparable to<BR>> early implementations of kernel space threading/thread suspending for<BR>> gc/...<BR>> <BR>> Any takers? :)<BR>> <BR>> <BR>> On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote:<BR>> > Yes, that's pretty much what modern Java implementations do.<BR>> > <BR>> > <BR>> -- <BR>> Dragiša Durić <dragisha@m3w.org><BR>> <BR> </body>
</html>