[M3devel] win32 threads...now Juno sometimes hangs..

[Jay K]

I could have easily flubbed it but the one time I tried to debug your Broadcast change, I had a deadlock due to one thread having the cm/giant lock and waiting for cs/heap, and another thread vice versa. It's pretty easy to see in the debugger.

Given the presence of cm/giant on Win32 and not on pthreads, that doesn't seem too surprising.

?

And/or I could easily have mismerged.

 

 

 - Jay


 


From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Tue, 29 Sep 2009 10:01:16 -0400
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs..





None of what you say rings any bells.  I don't think any of this is in the BroadcastHeap stuff.  It *may* be similar to the POSIX hang that I fixed.  I'll need to look more closely at the ThreadWin32 code.  But you are getting corruption, not a hang, right?


On 29 Sep 2009, at 07:19, Jay K wrote:

Hi Tony. Sorry, I had made one large error in ThreadWin32.m3.
At least. The Enter/Leave mechanical replacement error.
 
However even with that, the idle thread stuff seemed to cause problems.
It was there forever, I realize.
 
Also, I should have done this first, but anyway, later, I tried merging back in your changes from Feb 16.
Somewhat they are moot (lock vs. LockMutex).
Somewhat they are already there (WaitHeap, heapCond => condition).
Somewhat they are trivial (fixing error messages).
 
That leaves, in my analysis, the BroadcastHeap change.
 
With this change however, /sometimes/ Juno hangs.
Is this, like, somehow equivalent to the Posix hang?
Is the current code the "best"?
 
Oh darn..it hangs either way. Just not often.
Could that be "similar" to the pthread problem?
Any chance you can look at it?
 
Thanks,
 - Jay






 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090929/6766575f/attachment-0002.html>