<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>I'd be curious what OpenJDK does on Windows...</div><br><div><div>On 21 Apr 2009, at 22:46, Jay wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: 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: 0; "><div class="hmmessage" style="font-size: 10pt; font-family: Verdana; ">did more "research" (search the web..)<br> <br>It sounds like:<br> if fairness not critical, and pre NT 4.0 compat is needed, there are options where mutex/lock=criticalsection<br> <br> If fairness is important, and NT 4.0 can be used, and perf can be degraded, then mutex/lock=kernel mutex, and use the SignalAndWait function<br> <br>They never seem to use a global lock like ours.<br> <br>Should we maybe adopt Boost's code?<br>e.g.:<br> <br><a href="http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/mutex.hpp">http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/mutex.hpp</a><br><a href="http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/condition_variable.hpp">http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/condition_variable.hpp</a><br> <br>I don't know, it all seems kind of unforunate.<br> <br>Perhaps there should be two types of locks, one that can be associated with a conditionvariable (kernel mutex), one that cannot (criticalsection)?<br> <br>I guess our implementation is quite simple and solves "all the problems" by throwing scalability right out -- lots of independent threads acquiring lots of independent locks will all interfere somewhat with each other, but not a ton. The "giant" lock protects too much data, but not for long durations.<br> <br>It might be interesting to see what cygwin does..but I notice..pthread is a superset, e.g. timedwait, trylock, etc.<br> <br> - Jay<br><br> <br><hr id="stopSpelling">From:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>Date: Tue, 21 Apr 2009 04:41:55 +0000<br>CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation?<br><br>I'm not keen on it.<br>Checking the version and having two implementation switched between at initialization would be ok though -- actually using function pointers like so:<br> <br>void DoSomething_v2(void) { }<br>void DoSomething_v1(void) { }<br>void DoSomething_init(void)<br>{<br> if (... )<br> DoSomething = DoSomething_v1;<br>else<br> DoSomething = DoSomething_v2;<br>DoSomething();<br>}<br> <br>void (*DoSomething)(void) = DoSomething_init;<br> <br>Something more if switching multiple pointers though -- switching a pointer to a struct of function pointers.<br> <br> <br> - Jay<br><br> <br><hr id="EC_stopSpelling">From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>Date: Tue, 21 Apr 2009 14:33:29 +1000<br>CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation?<br><br>Might not be such a bad thing ;-)<div><br><div><div>On 21 Apr 2009, at 14:14, Jay wrote:</div><br class="EC_EC_Apple-interchange-newline"><blockquote><span class="EC_EC_Apple-style-span" style="word-spacing: 0px; font: normal normal normal 12px/normal Helvetica; text-transform: none; color: rgb(0, 0, 0); text-indent: 0px; white-space: normal; letter-spacing: normal; border-collapse: separate; "><div class="EC_EC_hmmessage" style="font-size: 10pt; font-family: Verdana; ">Only if you drop support for pre-Vista versions.<br> <br> - Jay<br><br><br> <br>> From:<span class="EC_EC_Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> To:<span class="EC_EC_Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> Date: Tue, 21 Apr 2009 07:53:57 +1000<br>> CC:<span class="EC_EC_Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation?<br>><span class="EC_EC_Apple-converted-space"> </span><br>> Also, note that win32 now supports CVs directly! No need for<span class="EC_EC_Apple-converted-space"> </span><br>> semaphores.<br>><span class="EC_EC_Apple-converted-space"> </span><br>> On 20 Apr 2009, at 19:11, Jay wrote:<br>><span class="EC_EC_Apple-converted-space"> </span><br>> ><br>> > Searching the web...finds this which seems very relevant:<br>> ><br>> ><span class="EC_EC_Apple-converted-space"> </span><a href="http://birrell.org/andrew/papers/ImplementingCVs.pdf">http://birrell.org/andrew/papers/ImplementingCVs.pdf</a><br>> ><br>> > - Jay<br>> ><br>> ><br>> ><br>> > ----------------------------------------<br>> >> From:<span class="EC_EC_Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >> To:<span class="EC_EC_Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> >> Date: Mon, 20 Apr 2009 08:47:21 +0000<br>> >> Subject: [M3devel] crummy ThreadWin32.m3 implementation?<br>> >><br>> >><br>> >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls<span class="EC_EC_Apple-converted-space"> </span><br>> >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way.<br>> >><br>> >><br>> >> - Jay<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br></div></span></blockquote></div><br></div></div></span><br class="Apple-interchange-newline"></blockquote></div><br></body></html>