On Mon, 15 Nov 2010, Bert Freudenberg wrote:

> Having "wait" in the name at least would make it clear that this decreases the excessSignals.
>
> Is this to be used with a critical section? That's the only place "locked" occurs, but you did not put it in the mutex category.
>
> Maybe if could give an example where this method is needed we could think of a better name.

I added this method when I was about to fix SharedQueue (another mail 
without responses: 
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-November/155059.html 
). If we decide to keep the current SharedQueue implementation, then we 
have to fix it, because it's broken. For example SharedQueue >> #peek 
returns false results. I uploaded a possible fix to the Inbox 
(http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-November/155053.html 
) but it's not a complete solution.

Fox example SharedQueue >> #peek could be something like this with 
#passIfLocked::

 	readSynch passIfLocked: [ ^nil ].
 	^accessProtect critical: [
  		readPosition >= writePosition ifFalse: [
 			readSynch signal.
  			contentsArray at: readPosition ] ]

But it still has a weak point: if the process is terminated after 
#passIfLocked, but before or during the #critical: send, the signal of 
readSynch will be lost. Probably #critical:ifLocked: is more suitable for 
this, but it's intended to be used in mutual exclusion cases (normally 
readSynch has the same number of signals as the number of elements in the 
queue).

Btw the other changes in Kernel-ul.514 are more interesting IMHO.


Levente

>
> - Bert -
>
>
>
>