Hi guys!
I am hacking away on a Flow based client/server thingy and needed to use a Semaphore as a mutex. So I did something like this:
myMutex critical: [ ...code code... ^self ...code code...]
...and oops, got bitten by the fact that the Semaphore does not get signalled when I have a return in my critical code block! Of course, it was simple to rewrite the code without returns but...
Is there any particular reason (performance etc) that prevents us from changing the implementation of #critical: to this (thus not missing to signal the Semaphore)?:
critical: mutuallyExcludedBlock "Evaluate mutuallyExcludedBlock only if the receiver is not currently in the process of running the critical: message. If the receiver is, evaluate mutuallyExcludedBlock after the other critical: message is finished."
self wait. ^mutuallyExcludedBlock ensure: [self signal]
The funny thing is that this seems to work EXCEPT for one Unit test I have which seems to "hang" on the "self signal" part above. Funny enough, if I alt-. it and then just "proceed" it moves on!
Obviously I am missing some piece of the puzzle, right? In any case this should perhaps be mentioned in the comment to #critical:
regards, G�ran
PS. This is in a rather old image pdated to 2915 with JMM's Flow and SUnit 2.7.1. DS
===== G�ran Hultgren, goran.hultgren@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek
__________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
This is one of the first things I have to take care of every time I start a project in Squeak...actually, to avoid creating side effects, I usually add a new method called #safeCritical: instead of changing #critical:. For a long time, #ensure: had some bugs, but now that they seem to be resolved, it's probably time to change #critical:.
- Stephen
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Gvran Hultgren Sent: Sunday, September 02, 2001 12:27 PM To: squeak-dev@lists.squeakfoundation.org Subject: Semaphore>>critical: ?
Hi guys!
I am hacking away on a Flow based client/server thingy and needed to use a Semaphore as a mutex. So I did something like this:
myMutex critical: [ ...code code... ^self ...code code...]
...and oops, got bitten by the fact that the Semaphore does not get signalled when I have a return in my critical code block! Of course, it was simple to rewrite the code without returns but...
Is there any particular reason (performance etc) that prevents us from changing the implementation of #critical: to this (thus not missing to signal the Semaphore)?:
critical: mutuallyExcludedBlock "Evaluate mutuallyExcludedBlock only if the receiver is not currently in the process of running the critical: message. If the receiver is, evaluate mutuallyExcludedBlock after the other critical: message is finished."
self wait. ^mutuallyExcludedBlock ensure: [self signal]
The funny thing is that this seems to work EXCEPT for one Unit test I have which seems to "hang" on the "self signal" part above. Funny enough, if I alt-. it and then just "proceed" it moves on!
Obviously I am missing some piece of the puzzle, right? In any case this should perhaps be mentioned in the comment to #critical:
regards, Göran
PS. This is in a rather old image pdated to 2915 with JMM's Flow and SUnit 2.7.1. DS
===== Göran Hultgren, goran.hultgren@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek
Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
I believe your code is incorrect. Does Squeak use a termination exception to safely kill processes? If not, ignore the ramblings of a lunatic. If so, a window exists between the #wait and the #ensure: (right between the two statements). If the process is terminated in that window, the semaphore is not released. I have patched this in VisualWorks (same problem), but the makes use of some interesting conjectures about the VisualWorks jitter.
If you like, you can use my test:
100 timesRepeat: [ | s procs | s := Semaphore forMutualExclusion. procs := (1 to: 50) collect: [:i | [Processor yield. [s critical: []] repeat] forkAt: Processor activeProcess priority - 1]. procs do: [:p | (Delay forMilliseconds: 2) wait. p terminate]. (Delay forMilliseconds: 100) wait. s excessSignals = 0 ifTrue: [self error: 'Failure to release critical semaphore']].
On Sunday, September 2, 2001, at 11:27 am, Göran Hultgren wrote:
Hi guys!
I am hacking away on a Flow based client/server thingy and needed to use a Semaphore as a mutex. So I did something like this:
myMutex critical: [ ...code code... ^self ...code code...]
...and oops, got bitten by the fact that the Semaphore does not get signalled when I have a return in my critical code block! Of course, it was simple to rewrite the code without returns but...
Is there any particular reason (performance etc) that prevents us from changing the implementation of #critical: to this (thus not missing to signal the Semaphore)?:
critical: mutuallyExcludedBlock "Evaluate mutuallyExcludedBlock only if the receiver is not currently in the process of running the critical: message. If the receiver is, evaluate mutuallyExcludedBlock after the other critical: message is finished."
self wait. ^mutuallyExcludedBlock ensure: [self signal]
The funny thing is that this seems to work EXCEPT for one Unit test I have which seems to "hang" on the "self signal" part above. Funny enough, if I alt-. it and then just "proceed" it moves on!
Obviously I am missing some piece of the puzzle, right? In any case this should perhaps be mentioned in the comment to #critical:
regards, Gˆran
PS. This is in a rather old image pdated to 2915 with JMM's Flow and SUnit 2.7.1. DS
===== Gˆran Hultgren, goran.hultgren@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek
Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
Hi guys!
--- Mark van Gulik ghoul6@home.com wrote:
I believe your code is incorrect. Does Squeak use a termination
Could have guessed! :-)
exception to safely kill processes? If not, ignore the ramblings of a lunatic. If so, a window exists between the #wait and the #ensure: (right between the two statements). If the process is terminated in
Aha... tricky.
that window, the semaphore is not released. I have patched this in VisualWorks (same problem), but the makes use of some interesting conjectures about the VisualWorks jitter.
If you like, you can use my test:
100 timesRepeat: [ | s procs | s := Semaphore forMutualExclusion. procs := (1 to: 50) collect: [:i | [Processor yield. [s critical: []] repeat] forkAt: Processor activeProcess priority - 1]. procs do: [:p | (Delay forMilliseconds: 2) wait. p terminate]. (Delay forMilliseconds: 100) wait. s excessSignals = 0 ifTrue: [self error: 'Failure to release critical semaphore']].
So... you mean this should work with the original #critical:? And, I do not really understand your check for failure, if it works shouldn't excessSignals be 0?
I have obviously not been coding too much with Semaphores...
regards, G�ran
===== G�ran Hultgren, goran.hultgren@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek
__________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
Hi again!
[Snipped some stuff] Mark wrote:
If you like, you can use my test:
100 timesRepeat: [ | s procs | s := Semaphore forMutualExclusion. procs := (1 to: 50) collect: [:i | [Processor yield. [s critical: []] repeat] forkAt: Processor activeProcess priority - 1]. procs do: [:p | (Delay forMilliseconds: 2) wait. p terminate]. (Delay forMilliseconds: 100) wait. s excessSignals = 0 ifTrue: [self error: 'Failure to release critical semaphore']].
So... you mean this should work with the original #critical:? And, I do not really understand your check for failure, if it works shouldn't excessSignals be 0?
I tried this (well, not the exact same code but almost) and since it is a mutex the excessSignals start at 1 and should end there too. So the test is correct.
Anyway, it fails in a recent 3.1a Squeak as predicted both my implementation of #critical: and the current one. And predictably my implementation fails even easier since I have a larger "window" between the finish of the block and the signal to the Semaphore.
Ok... well, at this point I will let this go - this is definitely my area...
regards, G�ran
===== G�ran Hultgren, goran.hultgren@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek
__________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
squeak-dev@lists.squeakfoundation.org