[Q] Has SharedQueue a very subtle bug?

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Fri Apr 12 14:03:03 UTC 2002


Bert Freudenberg <bert at isg.cs.uni-magdeburg.de> wrote:
> 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. 

It's a "smart" performance thing. The idea is that if the queue is empty
(readPos=writePos) then
the queue can move the pointers down to the beginning of the
contentsArray and thus avoid
senseless growing. But you probably understood that of course. :-)

I would guess though that there might be other methods in SharedQueue we
would not want to
"interrupt" with size/isEmpty.

regards, Göran



More information about the Squeak-dev mailing list