Arc Forum | So... that's it? atomic? If so, does the fact that (= ...) are done (atomic .....

Arc Forum

1 point by almkglor 6337 days ago | link | parent

So... that's it? atomic? If so, does the fact that (= ...) are done (atomic ...) mean that I can just, well, write to a variable and automatically expect locking?

2 points by shiro 6337 days ago | link

For the first question: Yes, to me it appears atomic-invoke is the locking primitive and everything else is built on top of it.

For the second question: note that (= ...) only expands to atwith when the generalzed location appears in the place to be set. The simple assignment

    (= a (f x) b (f y))

isn't protected. (That is, some thread may see a state where a is updated but b isn't yet, for example).

    (++ a)

is also unsafe if a is shared between threads, since it expands to

    ((fn () (set a (+ a 1))))

OTOH,

    (++ (car a))

becomes

    (atomic-invoke 
      (fn nil (withs (gs1430 a gs1429 1) 
                ((fn (val) (scar gs1430 val)) 
                 (+ (car gs1430) gs1429)))))

so it seems safe.

-----