[squeak-dev] The Trunk: Kernel-ul.515.mcz
Levente Uzonyi
leves at elte.hu
Mon Nov 15 23:20:01 UTC 2010
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 -
>
>
>
>
More information about the Squeak-dev
mailing list
|