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