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

[Tony Hosking]

Right.


On Jun 8, 2012, at 7:50 AM, Jay K wrote:

> I don't fully understand the paper, but clearly people want to both avoid the function call, and the CAS.
>   And clearly this is viable and often profitable -- often times locks are only ever acquired by one thread, or are locked many times by one thread, then many times by another, etc. The tricky part is adapting to determine which locks benefit, and handling the "transitions" (or "bias revocation") when a "second" thread does acquire the lock.
>  
>  
> Traditional C/C++ systems are always going to have the function call.
> Whether or not the CAS can be optimized away in such "unmanaged" systems, I don't know.
> For example, Win32 SRWLOCKs have no "cleanup" function, nor a required "initialize" function, so that might limit the flexibility of the implementation, though certainly is also advantageous..
>  
>  
>  - Jay
>  
> From: jay.krell at cornell.edu
> To: dragisha at m3w.org; hosking at cs.purdue.edu
> Date: Fri, 8 Jun 2012 11:20:56 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 (windows condition variables)
> 
>  > 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, Win 32 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 va st 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 University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Mobile +1 765 427 5484

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