> > 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.  :)

Just as a general note I don't really think that there is real problem with
the non-thread safe version of signalSemaphoreWithIndex(). I did add the
thread safe version for the single reason that this kind of problem is
*very* hard to debug if you ever run over it but it's kinda hard to actually
construct a case where this happens (I never managed to come up with a
simple case although I tried hard). The thread safe version also only guards
signals that happen from *two* outside threads at the same time (e.g., when
doing some networking and sound or somesuch).

> 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.

True. If you have stuff running at interrupt time you definitely have to go
another way. Just as an example, the Win32 MIDI input (which is supposedly
called from the interrupt level) signals the occurance of data to another
thread which may spend some time in the synchronization lock.

  - Andreas