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


| The only bad thing in all this scheme is that the things are still
| called "semaphores" and the operation is called "signal", which isn't
| exactly right from the VM's perspective.  Perhaps "ensure-at-least-1" or
| "ensure1" is a better name for the VM's operation here.

How about "interrupt" ?

Pieter

|
| Lex
|
|
|
|
| "Pieter Emmelot" <emmelot at e-solutions.demon.nl> wrote:
| > Hello Squeakers,
| >
| > While working on a simple plugin for the xaudio MP3 decoder I
| noticed that
| > the signalSemaphoreWithIndex() isn't thread save (win32). A thread save
| > version is available (which solved my problem) but isn't in the
| VM struct.
| > Shouldn't the original signalSemaphoreWithIndex() entry in the
| VM struct use
| > the thread save version instead?
| >
| > I also noticed that Interpreter>>signalSemaphoreWithIndex: throws away
| > signals when the same semaphore is signaled more then once
| between VM polls.
| > A quick fix might be to remove some code;
| > -----
| > signalSemaphoreWithIndex: index
| > 	"If it is not there already, record the given semaphore
| index in the list
| > of semaphores to be signaled at the next convenient moment. Set the
| > interruptCheckCounter to zero to force a real interrupt check as soon as
| > possible."
| >
| > 	index <= 0 ifTrue: [^ nil].  "bad index; ignore it"
| >
| > 	interruptCheckCounter _ 0.
| > "allow the same semaphore to be signalled more then once by
| commenting out
| > the following lines.
| > 	1 to: semaphoresToSignalCount do: [:i |
| > 		(semaphoresToSignal at: i) = index ifTrue: [^ nil]].
| > "
| > 	semaphoresToSignalCount < SemaphoresToSignalSize ifTrue: [
| > 		semaphoresToSignalCount _ semaphoresToSignalCount + 1.
| > 		semaphoresToSignal at: semaphoresToSignalCount put: index].
| > -----
| > When on the subject: it may be convenient to log an error when
| signals are
| > discarded by the 'semaphoresToSignalCount <
| SemaphoresToSignalSize' check.
| > Is there already a mechanism in the VM to log such a 'should
| never happen'
| > things?
| >
| > Final question; How can I make sure that the pool dictionary in
| a change set
| > is initialized before the classes in the set are filed in? I tried
| > initializing it in the preamble but didn't had any luck.
| >
| > Thanks to Dan and all the others who make Squeak happen. I
| didn't think it
| > would be so much fun to work with!
| >
| > Pieter Emmelot (happy)
|
|