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

[Tony Hosking]

Agreed, but we should be able to inline the CAS, avoiding a function call.

On Jun 8, 2012, at 6:38 AM, Dragiša Durić wrote:

> At least under Linux, uncontended access to futex is (IMHO) CAS based, user space operation.  
> 
> Same thing?
> 
> 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 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/ffdeb189/attachment-0002.html>