[Q] Has SharedQueue a very subtle bug?

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Fri Apr 12 10:33:43 UTC 2002


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...

regards, Göran



More information about the Squeak-dev mailing list