This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-05-04
Channels
- # architecture (27)
- # bangalore-clj (4)
- # beginners (22)
- # boot (35)
- # cider (26)
- # cljs-dev (2)
- # cljsrn (3)
- # clojure (156)
- # clojure-austria (3)
- # clojure-dev (9)
- # clojure-italy (25)
- # clojure-nl (10)
- # clojure-poland (5)
- # clojure-sanfrancisco (1)
- # clojure-spec (6)
- # clojure-uk (64)
- # clojurescript (169)
- # core-async (13)
- # cursive (13)
- # datomic (63)
- # dirac (50)
- # duct (21)
- # editors (1)
- # emacs (6)
- # events (1)
- # fulcro (1)
- # java (22)
- # keechma (14)
- # leiningen (2)
- # luminus (4)
- # off-topic (23)
- # onyx (4)
- # parinfer (5)
- # pedestal (4)
- # re-frame (6)
- # reagent (4)
- # ring-swagger (7)
- # rum (4)
- # shadow-cljs (84)
- # specter (5)
- # sql (36)
- # tools-deps (76)
- # uncomplicate (3)
- # yada (4)
what is the reason why go state is held in a java.util.concurrent.atomic.AtomicReferenceArray
instead of an unsynchronized array ?
@leonoel whenever a go block pauses execution of the block can jump to a new thread. The Java memory model does not guarantee that all writes to the array would be flushed before the new thread picks up the go block.
Another option would be to create a class with fields marked as volatile, but doing this inline, inside a macro, via normal clojure code is impossible.
Now days it might be possible to do all of this via volatile!
, but volatile came after core.async was released
the JMM ensures that all writes performed before the channel lock release are made visible to threads subsequently aquiring the same lock
what writes though, I'm pretty sure that's not true for non volatile fields
I remember when I made the change from a normal array to a AtomicReferenceArray I did a fair amount of research on the topic and talked to a few people and came to the conclusion that it was needed. But that was also about 5 years ago.
I'm more than happy to be corrected.
I have no doubt you have think about this more than I am but I can't really figure out a scenario where visibility would not be enforced
and I'm pretty sure JMM guarantees applies to unsynchronized fields as well, if it were not the case the linked lists inside channels would be unsafe
that's a good point