<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
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: jay.krell@cornell.edu<BR>To: hosking@cs.purdue.edu<BR>Date: Tue, 21 Apr 2009 04:41:55 +0000<BR>CC: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation?<BR><BR>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
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: hosking@cs.purdue.edu<BR>To: jay.krell@cornell.edu<BR>Date: Tue, 21 Apr 2009 14:33:29 +1000<BR>CC: m3devel@elegosoft.com<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: 12px 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></body>
</html>