On Fri, 12 Apr 2002 goran.hultgren at bluefish.se wrote:

> I have been looking at #size and #isEmpty in SharedQueue. Those two
> methods are not protected by the accessProtect Semaphore. Since I don't
> really know that much about Squeak Process scheduling, my question is:
> 
> Could another Process call #size or #isEmpty when the first Process is
> at the exact point marked below:
> 
> peek
> 	"Answer the object that was sent through the receiver first and has not
> 
> 	yet been received by anyone but do not remove it from the receiver. If 
> 	no object has been sent, suspend the requesting process until one is."
> 
> 	| value |
> 	accessProtect
> 		critical: [readPosition >= writePosition
> 					ifTrue: [readPosition _ 1.
> ************HERE*************
> 							writePosition _ 1.
> 							value _ nil]
> 					ifFalse: [value _ contentsArray at: readPosition]].
> 	^value
> 
> Since I believe this is so I would say that #size could potentially give
> a rather large incorrect answer when the queue is in fact empty (which
> could cause that process to try to read the queue and block). #isEmpty
> could also answer false when it is in fact true.
> 
> I tried to provoke this error but failed - my testcode might have been
> wrong. I know this might be "nitpicking" but I am curious and if it is
> indeed a bug it could save someone hours of debugging chasing this down
> - it wouldn't happen very often...

Why does #peek modify the SharedQueue state at all? It shouldn't be 
necessary. Just remove these assignments. 

-- Bert