VM and Multithreaded plugins (was: Newbie questions)
lex at cc.gatech.edu
Wed Mar 15 00:41:20 UTC 2000
"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
> 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
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.
More information about the Squeak-dev