[Pharo-project] Fwd: [squeak-dev] SharedQueue does scale (was: Re: SharedQueue doesn't scale)
bschwab at anest.ufl.edu
Mon Oct 18 09:53:57 EDT 2010
I don't know if it's better (or even as good), but when the dust settles, it would be nice to have something _called_ SharedQueue that does what's expected of it and delegates to the improved classes. Another option would be to go through a deprecation period with SharedQueue.
From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse at inria.fr]
Sent: Monday, October 18, 2010 9:26 AM
To: Pharo Development
Subject: [Pharo-project] Fwd: [squeak-dev] SharedQueue does scale (was: Re: SharedQueue doesn't scale)
>> Thanks, Levente for giving a feedback.
>> Please, feel free to shape my classes in more complete from (such as
>> proper naming),
>> to make them ready for inclusion in both Squeak's and Pharo cores.
>> I propose the following names:
>> AtomicQueue (base class) -> AtomicCollection
>> FIFOQueue -> AtomicQueue
>> LIFOQueue -> AtomicStack
>> If you, or anyone else having better suggestions, speak now :)
> Sounds like good names.
>> In any case, i'm am open to discuss further details and possible
>> caveats of using new classes
>> to anyone interested in using them.
>> P.S. As a side note, i now can explain (to myself at first place), why
>> i intuitively choosed to used atomic swap
>> instead of CAS.
>> Because it fits better fits with smalltalk language semantics:
>> A swap operation in smalltalk implemented as two assignments:
>> x := y. y := z.
>> An assignments is basic operation, which have nothing to do with
>> late-bound nature of language.
>> Unless we going to introduce a meta-object protocol(s), which could
>> turn a simple assignment
>> into some message sends under the hood, it will remain a basic,
>> early-bound operation.
>> And even if we do, it is highly unlikely, that even then we will throw
>> away the old,
>> simple assignment, which identifies an assignment source & target at
>> compile time.
>> In contrast, a CAS operation , if written in smalltalk looks like:
>> (a == b ) ifTrue: [ a := c ]
>> so, it having two message sends (#== , #ifTrue:), and from strict,
>> pure language perspective,
>> this using a late-bound semantics (a message sends),
>> and as any message send, the message result and behavior cannot be
>> predicted at compile time
>> and therefore its wrong to assume that such statement could be an
>> atomic operation.
>> Unless, of course, we introduce a new language syntax which will
>> denote a CAS operation explicitly.
>> Best regards,
>> Igor Stasenko AKA sig.
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
More information about the Pharo-dev