3 ms·

Without locking primitives this is asking for data races.

• michaelsbradley 12y ago
  The use of immutable collections[1] could help, but at some point in most programs it will be necessary to synchronize "pieces of state" across processes/threads. Perhaps a high-level API for doing so could be adapted from Clojure's STM facilities[2]? [1] http://swannodette.github.io/mori/ http://swannodette.github.io/mori/ [&] http://facebook.github.io/immutable-js/docs/ http://facebook.github.io/immutable-js/docs/ [2] http://clojure.org/concurrent_programming http://clojure.org/concurrent_programming
  • ndesaulniers 12y ago
    If you make copies of immutable data collections to change state, why not just use message passing? If you're going to share memory, you're more likely to write lock free data structures than copy immutable collections around. Supposedly, the point of juggling razors is for speed.
    • michaelsbradley 12y ago
      Immutable collections don't have to be wholly copied – derived collections may share internally quite a bit of information with the original collection/s. That allows them to be both fairly efficient and yet safe when used across concurrent processes. The "tricky party" is when concurrent processed need to synchronize some reference. Facilities for such ops can be orthogonal to the implementation of immutable collections, and then the two can be used together to good effect.
      • ndesaulniers 12y ago
        That's interesting, I did not know that. While it sounds like a fair amount of work, it can't be too much more than designing lock free data structures. Do you have good references to the design of such structures, or should I follow the links you posted above?
        • michaelsbradley 12y ago
          This is probably a good start: http://hypirion.com/musings/understanding-persistent-vector-pt-1 http://hypirion.com/musings/understanding-persistent-vector-...