lex at cc.gatech.edu
Sun Mar 12 10:47:44 UTC 2000
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.
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!
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.
"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
> 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'
> 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)
More information about the Squeak-dev