[squeak-dev] Re: [Pharo-project] How about atomic value-swap bytecode?

Tom Rushworth tom_rushworth at mac.com
Wed Oct 13 19:04:48 UTC 2010


Hi Eliot,

On 2010-Oct-13, at 11:06, Eliot Miranda wrote:

> 
> 
> On Wed, Oct 13, 2010 at 9:41 AM, Tom Rushworth <tom_rushworth at mac.com> wrote:
> Hi Igor, Eliot,
> 
> Eliot, I'm not sure I understood your comment:
> 
> On 2010-Oct-13, at 08:55, Eliot Miranda wrote:
> 
> > Right.  And because Smalltak can't reify variables and CAS is an operation on a variable CAS can't be implemented as a primitive on
> > variables.  There's no way to express "pass a variable to a primitive", only "pass an expression (which may be the value of a variable)" to a
> > primitive".  One could do it with a primitive on an object, e.g. thisContext at: tempIndex compareWith: match andSetTo: expr, or anObject
> > instVarAt: varIndex compareWith: match andSetTo: expr but that's soooo ugly.  Hence I think it is better done using a special assignment
> > operator.
> 
> I mean one can't write
> 
>     | t |
>     self compare: t andSwap: expr

RIght.  I wasn't aware of the restriction on primitives, but I'm painfully aware of the "lvalue problem" in C code.  Fortunately for my sanity, C does let me declare cas(int *var, int match, int new).  It isn't pretty, but it gets the job done without a lot of extra fuss.  For Smalltalk we don't have that escape.
> 
> 
[snip]

> which I rejected and didn't read further.  Now I see the :=:.  I don't like this because it doesn't map as nicely to CAS which I like using.  I like the boolean result one gets fro CAS that says the assignment either happened or it didn't.  Atomic swap is more low-level.  I then have to inspect the value the variable used to have and undo the swap if it wasn't what was expected.  So

Yes, but "undo the swap" is a lot thornier problem than you might at first think.  What if some other thread has done a swap of its own before you can check for and perform your counter-swap? Your code avoids this by wrapping the check and undo in a [...] valueUninteruptibly, but that sort of defeats the whole point of an atomic exchange.  If you have [...] valueUninterruptibly, why not just use it for atomic swap too?
> 
> 
>         | var |
>         var ?= expr : match
> 
> is equivalent to
> 
>         [| var scratch |
>         scratch := expr.
>         var :=: scratch.
>         scratch == match
>             ifTrue: [true]
>             ifFalse: [var :=: scratch. false]] valueUninterruptibly
> 
> Hence I think :=: is too low-level.

Well we agree to some extent - I think it is too weak to be worth the effort of doing it when a stronger, much more useful ?:= operation can be done for the pretty close to the same amount of effort.
> 
>  
> 
> If that's the case, then they both need to be implemented with a special assignment operator, and Igor and I can get back to arguing the merits of the atomic swap versus the atomic compare and swap :).  If not, then Igor's swap has a clear advantage and I guess you can both ignore the rest of this email...
> 
> Um, mine /does/ use a special assignment operator, "?= :" :)

Yes, I saw that, sorry I wasn't clearer.  My question was more along the lines of "Eliot's needs an op, doesn't Igor's too?".

[snip]

Regards,

--
Tom Rushworth






More information about the Squeak-dev mailing list