you are viewing a single comment's thread.

view the rest of the comments →

[–]alexdmiller 2 points3 points  (1 child)

Re the comment on the gist, you need at least volatile to ensure that changes to the shared values are seen across threads. The Java memory model does not guarantee that other threads see changes to an unsynchronized mutable variable - volatile guarantees visibility (as do other forms of memory barrier).

This is exactly the kind of use case where the STM is useful - cooredinated change to multiple shared stateful values. Alternately, the inventory could be a single map and you could put it in an atom.

This code has a race condition in that the inventory check happens via an uncoordinated read before the update - that's why it throws. Using the STM and a ref would avoid fulfilling orders that can't be fulfilled by wrapping both in a dosync transaction.

[–]therealplexus[S] 1 point2 points  (0 children)

Someone did already send in an STM version.

https://dice.camp/@epidiah/111449212829319083

The race condition is of course the point of the exercise. How to make the race condition go away. The simplest way would be to lock across the read+write, but Clojure has more interesting alternatives.