3 ms·

> and probably Haskell somehow By design - pure values are always thread safe.

by dons 14y ago

masklinn 14y ago
Pure values are not really relevant: you still need to update a binding somewhere to synchronize, and that's sufficient for your race. The clojure example wouldn't be safe if atoms weren't compare-and-set: have collection state A, thread one applies A->B, thread two applies A->C, the two threads set the atom (atomically but not CAS) and an increment has been lost even though all values are pure.
- tomp 14y ago
  Yes, but the point is, that in a functional language, hash-tables need not be thread-safe, as they are immutable. Only the variable binding has to be transactional. In a functional language, the code would be: transaction { local a = !x local b = copy a with b[i] = a[i] + 1 x := b } where `!x` is referencing a transactional variable and `:=` is setting it.
  - masklinn 14y ago
    > Yes, but the point is, that in a functional language, hash-tables need not be thread-safe As I and you noted, that's irrelevant, making the collection "thread-safe" (in the usual acception of the term, namely that concurrent accesses to the collection will not put the collection in an incorrect state) would not fix the situation since the increment is done outside the collection. > Only the variable binding has to be transactional. My point being precisely that the binding still has to be transactional: pure values are not sufficient to save you. > In a functional language, the code would be: Erm... I know. And that's not "in a functional language" that's in haskell, other languages will use different solutions.
- dons 14y ago
  Mutating collections with shared state isn't what you do in pure Haskell, though. That's the difference between the now classic deterministic parallelism , and the newer side-effect oriented concurrency in Haskell using stm or mvars. Without side effects your /parallel/ code cannot but be thread safe. Because the language requires the implementation to ensure side effects under the hood are not observable -- using cas for example on thunk updates, as GHC does.

> and probably Haskell somehow By design - pure values are always thread safe.

by dons 14y ago

> and probably Haskell somehow By design - pure values are always thread safe.

Pure values are not really relevant: you still need to update a binding somewhere to synchronize, and that's sufficient for your race. The clojure example wouldn't be safe if atoms weren't compare-and-set: have collection state A, thread one applies A->B, thread two applies A->C, the two threads set the atom (atomically but not CAS) and an increment has been lost even though all values are pure.

tomp 14y ago
Yes, but the point is, that in a functional language, hash-tables need not be thread-safe, as they are immutable. Only the variable binding has to be transactional. In a functional language, the code would be: transaction { local a = !x local b = copy a with b[i] = a[i] + 1 x := b } where `!x` is referencing a transactional variable and `:=` is setting it.
- masklinn 14y ago
  > Yes, but the point is, that in a functional language, hash-tables need not be thread-safe As I and you noted, that's irrelevant, making the collection "thread-safe" (in the usual acception of the term, namely that concurrent accesses to the collection will not put the collection in an incorrect state) would not fix the situation since the increment is done outside the collection. > Only the variable binding has to be transactional. My point being precisely that the binding still has to be transactional: pure values are not sufficient to save you. > In a functional language, the code would be: Erm... I know. And that's not "in a functional language" that's in haskell, other languages will use different solutions.
dons 14y ago
Mutating collections with shared state isn't what you do in pure Haskell, though. That's the difference between the now classic deterministic parallelism , and the newer side-effect oriented concurrency in Haskell using stm or mvars. Without side effects your /parallel/ code cannot but be thread safe. Because the language requires the implementation to ensure side effects under the hood are not observable -- using cas for example on thunk updates, as GHC does.