[M3devel] crummy ThreadWin32.m3 implementation?

[Tony Hosking]

I'd be curious what OpenJDK does on Windows...

On 21 Apr 2009, at 22:46, Jay wrote:

> 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/20090422/017621b7/attachment-0002.html>