[M3devel] Juno/Thread/Win32 notes

[Tony Hosking]

On 21 Oct 2009, at 17:02, Jay K wrote:

> ThreadWin32.m3 almost exactly matches Birrel's design.
> The order of two unlocks is reversed. It probably doesn't matter.
> He says LockMutex/UnlockMutex are just P/V. Ours is a bit different.
> We have queueing on our locks which appears unncessary, but is maybe
> with in mind an optimization mentioned but now shown by Birrel --
> that of Signal with a lock held transfering a thread right
> to the mutex's wait list.

The queueing on mutexes does appear unnecessary, unless the  
optimization can be achieved.

>  Birrel also has one mutex per condition variable but that
> seems to maybe be incidental and not architectural.

The only reason to have it in the CV is to achieve the optimization,  
so you know to which mutex queue we should transfer the signalled/ 
broadcast thread.

>  I believe there is much room for performance improvement
> here, but if it is correct, it is ok for this release.
> As well, I believe lock/conditionvariables can be made to work
> in threads not created by the Modula-3 runtime, at least with
> a dependency on NT4 or Win2000 (QueueUserAPC to trigger alert).
> (owner = GetCurrentThreadId instead of T).

Sure.

> I put in a bunch of RTIO in Juno.
> Whenever it hangs, the Signal call doesn't actually occur.
> We have to try to figure out why.
> It is something in the Misc/misc calls.

What are the Misc/misc calls?

>  So ThreadWin32.m3 is fairly well vindicated (except
> maybe via some roundabout fashion).
>
>
> The heap corruption is now fairly rare in Juno.
> I don't know if it is consistent or not.
> The contents are, not sure of the address.
> I'll debug more.
>
>
> My next idea..since I think the corruption involves
> copying a pixmap over other data, is to alter all
> pixmaps to be composed of specific data, see if that
> occurs in the corruption, to try to confirm this
> part of my theory.
>
>
> If that holds, then the memcpys done by gc could
> check for the pattern (actually they could check
> anyway, I thought I tried that already, will try again).

The corruption comes outside of GC.  It's just that the GC dicovers  
it.  This should really be straightforward to catch, if you can make  
it occur deterministically.

>  As well, with ThreadWin32.m3 having gotten some fixes,
> getting various timestamps of the source tree might be
> a good idea.
>
>
> With ThreadWin32.m3 fairly well vindicated, we might
> declare the quality is high enough asis. ?
> But I'd like to keep investigating.
> (Anyone else can?)
>
>
> The doubt imho is now more cast upon the Win32 Trestle code.
> We might even try Cygwin configured to use Win32 threads
> and X Windows and see if that has the same bug.
>
>
> Later..
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091021/5b79f2c8/attachment-0002.html>