[M3devel] crummy ThreadWin32.m3 implementation?

[Jay]

did more "research" (search the web..)

 

It sounds like:

  if fairness not critical, and pre NT 4.0 compat is needed, there are options where mutex/lock=criticalsection

 

  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

 

They never seem to use a global lock like ours.

 

Should we maybe adopt Boost's code?

e.g.:

 

http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/mutex.hpp

http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/condition_variable.hpp

 

I don't know, it all seems kind of unforunate.

 

Perhaps there should be two types of locks, one that can be associated with a conditionvariable (kernel mutex), one that cannot (criticalsection)?

 

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.

 

It might be interesting to see what cygwin does..but I notice..pthread is a superset, e.g. timedwait, trylock, etc.

 

 - Jay

 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Tue, 21 Apr 2009 04:41:55 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation?



I'm not keen on it.
Checking the version and having two implementation switched between at initialization would be ok though -- actually using function pointers like so:
 
void DoSomething_v2(void) { }
void DoSomething_v1(void) { }
void DoSomething_init(void)
{
 if (... )
  DoSomething = DoSomething_v1;
else
  DoSomething = DoSomething_v2;
DoSomething();
}
 
void (*DoSomething)(void) = DoSomething_init;
 
Something more if switching multiple pointers though -- switching a pointer to a struct of function pointers.
 
 
 - Jay

 


From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Tue, 21 Apr 2009 14:33:29 +1000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation?

Might not be such a bad thing ;-) 



On 21 Apr 2009, at 14:14, Jay wrote:

Only if you drop support for pre-Vista versions.
 
 - Jay


 
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Tue, 21 Apr 2009 07:53:57 +1000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation?
> 
> Also, note that win32 now supports CVs directly! No need for 
> semaphores.
> 
> On 20 Apr 2009, at 19:11, Jay wrote:
> 
> >
> > Searching the web...finds this which seems very relevant:
> >
> > http://birrell.org/andrew/papers/ImplementingCVs.pdf
> >
> > - Jay
> >
> >
> >
> > ----------------------------------------
> >> From: jay.krell at cornell.edu
> >> To: m3devel at elegosoft.com
> >> Date: Mon, 20 Apr 2009 08:47:21 +0000
> >> Subject: [M3devel] crummy ThreadWin32.m3 implementation?
> >>
> >>
> >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls 
> >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way.
> >>
> >>
> >> - Jay
> 
> 

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