Stephen,

Thanks very much for the comment below. It helped me trace an obscure
synchronization problem in my code, where a protected: block returned
early, and so failed to signal the semaphore. I filed in Craigs exception
framework, and changed the critical: block in Semaphore, to something like:
block valueEnsuringIfCurtailed: [self signal]. This has fixed the problem,
and hopefully should fix the general case of early returns from blocks.

The exception handling framework is great for semaphore
stuff, and should be made a part of the base image
as soon as possible. Whenever I break out of endless loops
now, I can guarantee that all the semaphores will put themselves
into a consistent state upon resumption.

Peter


>This sounds suspiciously like something else I encountered when writing the
>External Memory stuff.  The problem I found was that there are numerous
>places in the collection hierarchy where explicit returns are found inside
a
>#do: block.  The example I encountered was:
>
>Collection>>includes: anObject
> "Answer whether anObject is one of the receiver's elements."
>
> self do: [:each | anObject = each ifTrue: [^true]].
> ^false
>
>...and where it caused problems for me was when you send #includes: to an
>instance of a WeakRegistry.  Since #do: in WeakRegistry is implemented as
>follows:
>
>do: aBlock
> ^self protected:[
> valueDictionary keysDo: aBlock.
> ].
>
>...the block will return from the #includes: context before the mutex
>Semaphore has been signaled...hence subsequent uses of the WeakRegistry
will
>result in an indefinte wait on a Semaphore that will never be signaled.
>
>The solution here seems to be an appropriate use of #ensure: blocks.  I
>think that has been added by Craig Latta's exception handling framework.
>
>As a temporary fix for my situation, I overrided #includes: in WeakRegistry
>as follows:
>
>includes: anObject
> "Answer whether anObject is one of the receiver's elements.
> Overridden here because the super implementation has an explicit
> return inside the do block...Squeak needs an implementation of #ensure:
> to handle this correctly.  Note: it's likely this issues will crop up
>elsewhere."
>
> self do: [:each |
> anObject = each ifTrue: [
> accessLock isNil ifFalse: [ accessLock signal ].
> ^true
> ]
> ].
> ^false
>
>...which is ugly.
>
>Hope that helps...in case it doesn't it might be useful for others.
>