[M3devel] Juno/Thread/Win32 notes

[Jay K]

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.

 


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

 


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).

 


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.

 


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).

 


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/057eda2a/attachment-0001.html>