[M3commit] CVS Update: cm3

[Tony Hosking]

On Jan 12, 2011, at 8:53 PM, Jay K wrote:

> 
> I haven't lookd, but it sounds like the idea is,
> use LockHeap/UnlockHeap instead of Lock/Unlock(initMu)?
> ie. resolve problems in a graph by merging nodes.

Yes.

> I was also wondering if, maybe, we can initialize
> mutexex/condition variables eagerly instead of on-demand?
> Therefore without locking?

Seems overkill for types that inherit from MUTEX but are never used for locking.  Also, ultimately a Modula-3 MUTEX won't be one-to-one with pthread mutexes.

> I know that currently there's no interface from the
> generated code to the runtime for that.
> 
> 
> It's a tradeoff. Presumably/hopefully there are many
> mutexes and condition variables that are never used,
> and initializing them would just be a slow down.

Precisely.

> 
> 
> - Jay
> 
> ----------------------------------------
>> Date: Thu, 13 Jan 2011 02:37:40 +0000
>> To: m3commit at elegosoft.com
>> From: hosking at elego.de
>> Subject: [M3commit] CVS Update: cm3
>> 
>> CVSROOT: /usr/cvs
>> Changes by: hosking at birch. 11/01/13 02:37:40
>> 
>> Modified files:
>> cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.i3
>> ThreadPThread.m3
>> ThreadPThreadC.c
>> 
>> Log message:
>> Revert to old LockHeap/UnlockHeap inplementation, but retain LockHeap for
>> InitMutex instead of initMu to avoid deadlock between Initmutex and
>> AtForkParent.
>>