[M3devel] [M3commit] CVS Update: cm3

[Tony Hosking]

On 12 Sep 2009, at 05:26, Jay K wrote:

> Tony,
>  - You didn't like how I factored InitMutex and InitCondition via  
> InitMutexHelper?

Please keep them separate in case implementation of Condition and  
Mutex diverge.  I've been playing with these some lately and may yet  
make further changes.  Having shared code makes it a real pain to  
change one and not the other.

>  - XWait doesn't have to initialize the mutex, because it must already
>    be locked, and therefore initialized? Or is that a "safety hole"?

Just in case a client invokes Wait without holding the mutex.  Perhaps  
better to check and die.  I will adjust.

>    Unsafe module trusting safe caller to have adhered to its interface
>    but it might not have to so unsafe code has to do extra work to  
> preserve safety?
>    Reasonable to ASSERT instead? Or are asserts allowed to be removed

ASSERTs can be removed by compiling without assertions for performance.

>    and can't be used to guarantee safety?

Right.

>    (I put them in C code used by Modula-3, but I can perhaps make  
> the rules there.)

C coded asserts cannot be turned off by the Modula-3 compiler.  Only C  
compiler.

>
>  - Jay
>
>
>
>
>
>
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sat, 12 Sep 2009 08:53:01 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>
> 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/e3080e03/attachment-0002.html>