[BUG]Collection>>removeAll:
Allen Wirfs-Brock
Allen_Wirfs-Brock at Instantiations.com
Thu Aug 22 22:51:17 UTC 2002
At 04:11 PM 8/22/2002 -0600, David Farber wrote:
>Tim -- What is wrong with the semantics of copying a collection before you
>iterate over it? If that was how do: were implemented, how would
(I really don't know why I want to insert myself into the middle of this
"discussion, but...)
Because copying the collection, it self, may not be an operation that is
stable in the presence of concurrent updates and access). That's the root
problem -- the Smalltalk collections are not implemented to function
correctly in the presence of concurrent updates. It doesn't matter whether
the concurrency occurs using multiple threads or with a single thread
because of "aliasing", it's still concurrent. It is possible to design
collections that work correctly in the presence of concurrent updates, but
it is not necessarily desirable in all situations as this can introduce
very significant performance degradations in the "normal" situation where
there is not concurrent updates.
#addAll: and #removeAll: where the receiver and argument are the same
object are clearly special cases as the "correct" semantics of those cases
is far from obvious. This is true even if the underlying implementation
safely supports concurrent updates. ANSI Smalltalk neglected to define
these cases. I consider this to be an oversight. If somebody had brought
this to our attention we would have said something about these special
cases. What we probably would have said is something like: "if the
receiver and the argument are the same object, the result is undefined"
(the stock standards committee answer to something for which there is no
consensus or obvious correct answer).
Personally, I think a:
self == argCollection ifTrue: ...
test at the beginning of removeAll: and addAll: would be a quite reasonable
thing with almost no performance impact for real programs. I leave you
all to debate, what should appear in the ifTrue: clause.
Allen_Wirfs-Brock at Instantiations.com
More information about the Squeak-dev
mailing list
|