[M3devel] Juno/Thread/Win32 notes

[Tony Hosking]

On 22 Oct 2009, at 01:21, Jay K wrote:

>  > The only reason to have it in the CV is to achieve the  
> optimization,
>  > so you know to which mutex queue we should transfer the signalled/ 
> broadcast thread.
>
>
> Of course. I should have realized that.
> Um..the data is available anyway though, isn't it?
> The thread had to call wait(mutex, condition) in order for  
> signal(condition) to unlink him from the condition's waiters, the  
> waiting thread can store the mutex in itself (he can only be waiting  
> on one condition variable at a time) and the signaling thread can  
> grab that.
> I think.

You may need to know which mutex to move the thread to upon alert.

>  In either case, I'm not too inclined to touch it for this release  
> until we are sure there is a bug, and that looks unlikely at this  
> point. We could try putting back your BroadcastHeap change?

I don't think that is in any way broken.

>  It also seems a little gross that the heap lock is a special case  
> recursive mutex.
> It seems like we should have Mutex and RecursiveMutex, have either  
> work with Condition, and have LockHeap/UnlockHeap/BroadcastHeap just  
> be wrappers around that.

The heap lock cannot be an object allocated in the heap.

>  More generally we should probably try to embelish Thread.i3 with  
> more primitives I think. At least "interlocked" and "once", if not  
> "event" and "semaphore".
> "once" could definitely see a fair amount of use.

Yuck.  Thread.i3 is a standard interface and should not change.   
Modula-3 has strong ideas about what thread primitives should be.

> The rest maybe not, maybe they are too primitive and hard to get  
> good use out of, hard to define portably/efficiently.
>
>
> Or maybe LockHeap/UnlockHeap recursive support could/should be  
> removed and just stick with Mutex and Condition and nothing else?

Again.  These are needed inside GC when  one cannot touch heap objects.

>
>
> Well, reader/writer locks are nice.

...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091022/1a327198/attachment-0002.html>