I'll defer to Timothy on the particulars of core.async but it looks like [1] the transducer in channel is protected by a lock. If that's the case volatile isn't adding anything in terms memory barriers.
1: https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj#L71 On Sunday, April 9, 2017 at 11:58:00 AM UTC-5, Alexander Gunnarson wrote: > > Thanks so much for your well-considered reply, Timothy! That makes sense > about volatiles being used in e.g. core.async or core.reducers contexts > where the reducing function that closes over the mutable value of the > stateful transducer is called in different threads. Why, then, are > unsynchronized ArrayLists used e.g. in 'partition-by'? It's also closed > over by the reducing function in just the same way as the volatile long > value internal to e.g. 'map-indexed'. I'm not yet clear on how one (the > ArrayList) is acceptable being non-volatile and the other (the volatile > long) is unacceptable. When .add is called, an unsynchronized mutable > counter is updated so the ArrayList can insert the next value at the > correct index. Do you have any insight into this? Meanwhile I'll go do some > digging myself on the Clojure JIRA etc. so I'm more informed on the > subject. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
