"Pieter Emmelot" <emmelot at e-solutions.demon.nl> wrote:
> | From: Lex Spoon [mailto:lex at cc.gatech.edu]
> | I think the idea is that these semaphores are only used to wake up an
> | image-level process, which then will do as much work as possible.
> | Signalling the semaphore twice in a row is thus not useful, but it won't
> | cause any harm.
> 
> Since the Semaphore>>signal method counts I assumed I would get the same
> behaviour calling the VM...

The terminology is certainly misleading.  But is the current situation
actually bad?  It seems like a pretty good setup to me.  It's simple,
safe, and AFAICT sufficient for most purposes.


> 
> 
> | The big advantage is that you don't have to lock the semaphore when you
> | signal it from the VM.  When you consider that you may well be inside an
> | interrupt when you signal a semaphore, then this is important!
> 
> I don't think that's true when you consider that more then one
> thread/interrupt can call signalSemaphoreWithIndex().
> When I call signalSemaphoreWithIndex() from a xaudio callback the VM crashes
> within 10 seconds when playing music.
> Using the thread save version of signalSemaphoreWithIndex() fixes the
> problem.
> IMHO the interperter should also lock before accessing the semaphore related
> datastructure. The code is already there (on WIN32 at least) so why not fix
> it?
> 
> 


If it's not working, that's a shame.  If you can get a minimal example
of this deadlock, please to post it so it can be fixed.  I used the
mechanism when working on sound support on Linux, and didn't see any
such problems, so it works at least sometimes.  :)

In fact, simply adding a lock around all accesses introduces a deadlock
by design: suppose the interpreter is interrupted while it has the lock,
and then the interrupt code also tries to obtain the lock.  The
interrupt would block, which is a really bad situation.



Lex