[M3devel] [M3commit] CVS Update: cm3

Sat Sep 12 15:18:03 CEST 2009

If you do that, can you make it decide at runtime to chose between a pre-Vista and Vista or newer implementation?

If you want, I can create ThreadWin6.m3 that is actually identical to ThreadWin32.m3 and a runtime switch between them, and then you or maybe I can start changing ThreadWin6.m3.

I'm going to try to "study" ThreadPThread.m3 to inform me on how to write both ThreadWinNoCV.m3 (fix) and ThreadWinCV.m3 (making up more names).

Thanks,

 - Jay

From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Sat, 12 Sep 2009 08:24:48 -0400
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] [M3commit] CVS Update: cm3

Interesting.  My suspicions are that I missed something in the ThreadWin32 conversion to implement LockHeap, WaitHeap sanely.  I can't debug Windows threads easily, but I strongly suggest Windows threads are in need of a rewrite to improve concurrency by making use of mutex/CVs now that Win32 supports CVs.

On 12 Sep 2009, at 04:53, Jay K wrote:

I believe it was this 30 minute window, 2009-02-16 02:00 - 2009-02-16 02:30:

2009-02-16 02:30  hosking

  * m3-libs/m3core/src/runtime/POSIX/: RTProcessPosixC.c,
    RTProcessPosixC.i3:

  Tidy up.

2009-02-16 02:20  hosking

  * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c,
    Csupport/little-endian/dtoa.c, convert/CConvert.i3,
    convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3,
    runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3,
    runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3,
    thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3,
    thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3,
    thread/WIN32/ThreadWin32.m3:

  Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics.
  This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held.
  RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not.

2009-02-16 02:02  hosking

  * m3-libs/m3core/src/runtime/common/RTHeapMap.i3:

  Expose DoWalkRef.

 - Jay

From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Fri, 11 Sep 2009 22:21:44 -0400
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] [M3commit] CVS Update: cm3

Hmmm.  Not sure.  Do you have the code diffs?

On 11 Sep 2009, at 17:28, Jay K wrote:

They aren't really in Trestle or ThreadWin32.
Well, right, often they are in ThreadWin32.
But not always.
I think it is, like, classic heap/stack corruption, via non-classic "locking not working" and gc moving stuff when it shouldn't.
I don't have good evidence, but it usually NOT a hang/deadlock or assertion failure, it is usually an access violation (aka SEGSIGV) which as I understand must be the result of bugs in unsafe code.

I did narrow it down a 30 minute window.

 - Jay

From: hosking at cs.purdue.edu
To: rcoleburn at scires.com
Date: Fri, 11 Sep 2009 17:05:57 -0400
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] [M3commit] CVS Update: cm3

I have my suspicions that ThreadWin32 may have similar latent bugs in synchronization similar to those I have recently shaken out of the pthreads implementation.  The good thing is that my implementation there is based in part on ThreadWin32, so it can't be too far off.  It is inevitable with concurrent code that you will get different behavior at each run.  The easiest things to debug are thread lockups, which can usually be diagnosed by staring at dumps of all the thread state.  Harder is actual crashes like you are observing.  If assertions can be used to monitor program invariants then it usually can be narrowed down.  Unfortunately, I am not in a position to debug the ThreadWin32 code.  Any help would be appreciated.  The question is whether the crashes you see are in Trestle or ThreadWin32.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484

On 11 Sep 2009, at 16:54, Randy Coleburn wrote:

Tony:

Will any of this make any difference on Windows platform?

I tried a couple of days ago to update all sources and rebuild.  Both Juno and Mentor still crash on both XP and Vista.  If you run multiple times, you get different crash results.  (So much for deterministic behavior.)  Let me know if there is anything I can do to help debug/test.

Regards,
Randy

>>> Antony Hosking <hosking at elego.de> 9/11/2009 10:48 PM >>>
CVSROOT:/usr/cvs
Changes by:hosking at birch.09/09/11 22:48:37

Modified files:
cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 

Log message:
Mentor and Juno finally work on I386_DARWIN.
***Significant overhaul of thread alerting.***
Invariant now is that all waiting is done on the thread's own condition
variable.  This cleanly permits signals and alerts from any other thread.

Need  to set DISPLAY=:0.0 and xhost+ to get around problems with
DISPLAY=/tmp/launch-XXXXXX/:0.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090912/4cb54baf/attachment-0002.html>