Re: Java memory model & stateful tranducers

> > And then I think it is the responsibility of the transducing context to > lock appropriately to ensure visibility (if needed). Totally agree, that's why volatile instead of unsynchronized in transducer sounds like belt and suspenders to me. On Wednesday, December 7, 2016 at 7:00:09 PM UT

Re: Java memory model & stateful tranducers

I think the reason for some things being volatile and some not is that we want all of that stuff to be stateful. The volatile ones are making things stateful by explicitly creating a stateful Clojure container for immutable values. The ArrayLists are inherently stateful because they are mutable

Re: Java memory model & stateful tranducers

Transducers are expected to be invoked always in a single thread context. Everything in core maintains that by just running it in a single thread. core.async channels may be invoked from many threads, but only one at a time, and channel itself properly locks to make that state visible. That sai

Java memory model & stateful tranducers

Hi ! I'm a bit confused about the official design rules for stateful transducers and transducing contexts, especially about which one should be in charge of memory visibility guarantees. The common practice seems to be using volatiles to hold state in transducers (e.g distinct