[M3devel] [M3commit] CVS Update: cm3 (windows condition variables)

[Jay K]

 > At least under Linux, uncontended access to futex is (IMHO) CAS based, user space operation.   So is uncontended Win32 critical section and uncontended Win32 SRWLOCK. Just disassemble and/or step through them... Mutex/Semaphore/Event, those always go to the kernel, unfortunately.  So our win32 condition-variable-ish stuff might, I have to check. It'd be unfortunate, but it still probably as good as it can be, short of depending on Vista. (Uncontended Vista+ condition variables surely don't involve the kernel either.)  The CAS isn't inlined. There is a function call. A dynamically linked one, so at least on Win32, it goes through a function pointer, but other than inlining factors, it can still be very fast. It can bias to a thread, and such. But there will be a function call.   - Jay Subject: Re: [M3devel] [M3commit] CVS Update: cm3 (windows condition variables)
From: dragisha at m3w.org
Date: Fri, 8 Jun 2012 12:48:47 +0200
CC: m3devel at elegosoft.com; jay.krell at cornell.edu
To: hosking at cs.purdue.edu


On Jun 8, 2012, at 12:38 PM, Dragiša Durić wrote:At least under Linux, uncontended access to futex is (IMHO) CAS based, user space operation.  
Same thing?


Meaning:  "At least under Linux, Modula-3 using pthreads does same thing as modern JVMs?"

On Jun 8, 2012, at 12:25 PM, Tony Hosking wrote:My point is that modern JVMs, including Sun/Oracle HotSpot, don't map every synchronized statement to an invocation of an underlying pthread or win32 lock.  Instead, they use fast processor synchronization primitives like CAS compiled into the code to quickly "lock" an object in the vast majority of cases when no other thread is trying to lock the same object, without mapping to some pthread or win32 mutex.
On Jun 8, 2012, at 5:23 AM, Jay K wrote:sorry -- clarification, we are similar to the widely used Sun/Oracle JVM.
Not necessarily state-of-the-art, but not bad.
 
 
Our locks map pretty directly to underlying pthread mutex, Win32 critical section.
Maybe not 100% directly. Maybe we delay-heap-allocate-and-initialize, i.e. so lock declaration/creation is super cheap -- just leave room for a pointer -- but there is a small extra code per lock acquire/release.
 
 
Our condition variable functionaliy maps pretty directly to pthread condition variables.
Prior to Vista, there were no Win32 condition variables, but what we do is pretty good, better than many implementations out there (e.g. older Modula-3, Boost) and similar to widely used implementations, e.g. Sun/Oracle Java. In particular we do not have a giant lock for condition variable operations, which some literature says you need.
 
 
Historically the Win32 Modula-3 threading library had a giant lock to aid in condition variable implementation.
It was pretty bad.
 
 
Since pthread and Win32 are widely used, hopefully they are really good, and if not, will be improved for the vast majority of code to reuse. Tony, in your research, you should be sure to compare against Win32 SRWLOCK and newer versions of Windows (i.e. newer than XP). I'll try to read your paper.
 
 
 - Jay
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 (windows condition variables)
> From: antony.hosking at gmail.com
> Date: Fri, 8 Jun 2012 04:38:20 -0400
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> To: dragisha at m3w.org
> 
> 
> On Jun 8, 2012, at 4:06 AM, Dragiša Durić wrote:
> 
> > Please explain this more, and if you can - draw parallel to *nix.
> > 
> > TIA
> > 
> > On Jun 8, 2012, at 4:05 AM, Jay K wrote:
> > 
> >> Note though that "LOCK" doesn't map directly to EnterCriticalSection and more significantly, m3core provides essentially condition variables, which don't map directly to Win32, prior to Vista.
> >> (LOCK at least does a delay-heap-allocation-and-initialize before EnterCriticalSection, but also interacts with the condition variables I recall.)
> >> 
> >> 
> >> I did a bunch of "research" and our condition variable substitution is pretty good now, equivalent to what Java implementations do.
> >> Definitely better than others e.g. Boost.
> 
> We are certainly NOT equivalent to state-of-the-art Java implementations. Take a look at http://dx.doi.org/10.1145/2093157.2093184 for example.
> 
> - Tony
> 




Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAMobile +1 765 427 5484




 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120608/0f5c5629/attachment-0002.html>