<html><head><base href="x-msg://247/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Right.<div><br><div>
<br><div><div>On Jun 8, 2012, at 7:50 AM, Jay K wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="hmmessage" style="font-size: 10pt; font-family: Tahoma; "><div dir="ltr">I don't fully understand the paper, but clearly people want to both avoid the function call, and the CAS.<br>  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.<br> <br> <br>Traditional C/C++ systems are always going to have the function call.<br>Whether or not the CAS can be optimized away in such "unmanaged" systems, I don't know.<br>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..<br> <br> <br> - Jay<br> <br><div><hr id="stopSpelling">From: <a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To: <a href="mailto:dragisha@m3w.org">dragisha@m3w.org</a>; <a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>Date: Fri, 8 Jun 2012 11:20:56 +0000<br>CC: <a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: Re: [M3devel] [M3commit] CVS Update: cm3 (windows condition variables)<br><br><div dir="ltr"> > At least under Linux, uncontended access to futex is (IMHO) CAS based, user space operation.<br> <br> <br> So is uncontended Win32 critical section and uncontended Win32 SRWLOCK. Just disassemble and/or step through them...<br> Mutex/Semaphore/Event, those always go to the kernel, unfortunately.<span class="Apple-converted-space"> </span><br> 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.)<br> <br> <br>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.<br> <br> <br> - Jay<br> <br><div><div id="ecxSkyDrivePlaceholder"></div><hr id="ecxstopSpelling">Subject: Re: [M3devel] [M3commit] CVS Update: cm3 (windows condition variables)<br>From: <a href="mailto:dragisha@m3w.org">dragisha@m3w.org</a><br>Date: Fri, 8 Jun 2012 12:48:47 +0200<br>CC: <a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a>; <a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To: <a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br><br><br><div><div>On Jun 8, 2012, at 12:38 PM, Dragiša Durić wrote:</div><br class="ecxApple-interchange-newline"><blockquote><div>At least under Linux, uncontended access to futex is (IMHO) CAS based, user space operation.  <div><br></div><div>Same thing?<br><div><br></div></div></div></blockquote><div><br></div>Meaning:  "At least under Linux, Modula-3 using pthreads does same thing as modern JVMs?"</div><div><br></div><div><br><blockquote><div><div><div><div><div>On Jun 8, 2012, at 12:25 PM, Tony Hosking wrote:</div><br class="ecxApple-interchange-newline"><blockquote><div>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.<div><div><br><div><div>On Jun 8, 2012, at 5:23 AM, Jay K wrote:</div><br class="ecxApple-interchange-newline"><blockquote><span class="ecxApple-style-span" style="text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; border-collapse: separate; orphans: 2; widows: 2; "><div class="ecxhmmessage" style="font-family: Tahoma; font-size: 10pt; "><div dir="ltr">sorry -- clarification, we are similar to the widely used Sun/Oracle JVM.<br>Not necessarily state-of-the-art, but not bad.<br> <br> <br>Our locks map pretty directly to underlying pthread mutex, Win 32 critical section.<br>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.<br> <br> <br>Our condition variable functionaliy maps pretty directly to pthread condition variables.<br>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.<br> <br> <br>Historically the Win32 Modula-3 threading library had a giant lock to aid in condition variable implementation.<br>It was pretty bad.<br> <br> <br>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.<br> <br> <br> - Jay<br><div><div id="ecxSkyDrivePlaceholder"></div>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 (windows condition variables)<br>> From:<span class="ecxApple-converted-space"> </span><a href="mailto:antony.hosking@gmail.com">antony.hosking@gmail.com</a><br>> Date: Fri, 8 Jun 2012 04:38:20 -0400<br>> CC:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>;<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> To:<span class="ecxApple-converted-space"> </span><a href="mailto:dragisha@m3w.org">dragisha@m3w.org</a><br>><span class="ecxApple-converted-space"> </span><br>><span class="ecxApple-co
 ecxnverted-space"> </span><br>> On Jun 8, 2012, at 4:06 AM, Dragiša Durić wrote:<br>><span class="ecxApple-converted-space"> </span><br>> > Please explain this more, and if you can - draw parallel to *nix.<br>> ><span class="ecxApple-converted-space"> </span><br>> > TIA<br>> ><span class="ecxApple-converted-space"> </span><br>> > On Jun 8, 2012, at 4:05 AM, Jay K wrote:<br>> ><span class="ecxApple-converted-space"> </span><br>> >> 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.<br>> >> (LOCK at least does a delay-heap-allocation-and-initialize before EnterCriticalSection, but also interacts with the condition variables I recall.)<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"><span class="Apple-converted-space"> </span> </span><br>> >> I did a bunch of "research" and our condition variable substitution is pretty good now, equivalent to what Java implementations do.<br>> >> Definitely better than others e.g. Boost.<br>><span class="ecxApple-converted-space"> </span><br>> We are certainly NOT equivalent to state-of-the-art Java implementations. Take a look at<span class="ecxApple-converted-space"> </span><a href="http://dx.doi.org/10.1145/2093157.2093184" target="_blank">http://dx.doi.org/10.1145/2093157.2093184</a><span class="ecxApple-converted-space"> </span>for example.<br>><span class="ecxApple-converted-space"> </span><br>> - Tony<br>><span class="ecxApple-converted-space"> </span><br></div></div></div></span></blockquote></div><br></div></div><br><br><div><span class="ecxApple-style-span" style="text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; border-collapse: separate; orphans: 2; widows: 2; "><span class="ecxApple-style-span" style="font: normal normal normal 12px/normal Helvetica; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; border-collapse: separate; orphans: 2; widows: 2; "><div><span class="ecxApple-style-span" style="font: normal normal normal 12px/normal Helvetica; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; border-collapse: separate; orphans: 2; widows: 2; "><div><span class="ecxApple-style-span" style="font: normal normal normal 12px/normal Helvetica; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; border-collapse: separate; orphans: 2; widows: 2; "><span class="ecxec
 ecxxApple-style-span" style="font: normal normal normal 12px/normal Helvetica; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; border-collapse: separate; orphans: 2; widows: 2; "><span class="ecxApple-style-span" style="font: normal normal normal 12px/normal Helvetica; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; border-collapse: separate; orphans: 2; widows: 2; "><span class="ecxApple-style-span" style="font: normal normal normal 12px/normal Helvetica; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; border-collapse: separate; orphans: 2; widows: 2; "><span class="ecxApple-style-span" style="font: normal normal normal 12px/normal Helvetica; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; border-collapse: separate; orphans: 2; widows: 2; "><span class="ecxApple-style-span" style="font: normal normal normal 12px/normal Helvetica; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; border-collapse: separate; orphans: 2; widows: 2; "><span class="ecxApple-style-span" style="font: normal normal normal 12px/normal Helvetica; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; border-collapse: separate; orphans: 2; widows: 2; "><span class="ecxApple-style-span" style="font: normal normal normal 12px/normal Helvetica; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; border-collapse: separate; orphans: 2; widows: 2; "><div><font class="ecxApple-style-span" color="#0000ff"><font class="ecxApple-style-span" face="Gill Sans"><span class="ecxApple-style-span" style="color: rgb(0, 0, 255); font-family: 'Gill Sans'; "><span class="ecxApple-style-span" style="color: rgb(0, 0, 255); font-family: 'Gill Sans'; ">Antony Hosking</span></span></font></font><font class="ecxApple-style-span" face="Gill Sans"><span class="ecxApple-style-span"><span class="ecxApple-style-span" style="font-family: 'Gill Sans'; "><span class="ecxApple-converted-space"> </span>|<span class="ecxApple-converted-space"> </span></span></span><span class="ecxApple-style-span" style="font-family: 'Gill Sans'; "><span class="ecxApple-style-span" style="font-family: 'Gill Sans'; ">Associate Professor</span></span><span class="ecxApple-style-span" style="font-family: 'Gill Sans'; "><span class="ecxApple-style-span" style="font-family: 'Gill Sans'; "> | Computer Science | Purdue University</span></span></font></div><div><font class="ecxApple-style-span" face="GillSans-Light"><span class="ecxApple-style-span" style="font-family: GillSans-Light; ">305 N. University Street | West Lafayette | IN 47907 | USA</span></font></div><div><font class="ecxApple-style-span" color="#0000ff" face="Gill Sans"><span class="ecxApple-style-span" style="color: rgb(0, 0, 255); font-family: 'Gill Sans'; "><span class="ecxApple-
 ecxstyle-span" style="color: rgb(0, 0, 255); font-family: 'Gill Sans'; ">Mobile</span></span></font><font class="ecxApple-style-span" face="GillSans-Light"><span class="ecxApple-style-span" style="font-family: GillSans-Light; "><span class="ecxApple-style-span" style="font-family: GillSans-Light; "><span class="ecxApple-converted-space"> </span>+1 765 427 5484</span></span></font></div></span></span></span></span></span></span></span></span></div></span></div></span></span></div></div></blockquote></div></div></div></div></blockquote></div></div></div></div></div></div></span></blockquote></div><br></div></div></body></html>