> > >> Transducers should ensure stateful changes guarantee visibility. That is: >> you should not make assumptions about external memory barriers. > > > How do you enforce no more than one thread at a time without setting a > memory barrier ? >
I could have one thread that invokes a transduce step on odd seconds and another that invokes on even seconds. Or some external api call that tells me to take the next step, which I do on a thread pulled from a pool. I'm sure I could come up with others. > For the JMM, no more than one thread at a time means exactly that return > of step n will *happen-before* the call to step n+1. > happens-before across threads requires a volatile or lock, but I don't see how the use of one is guaranteed by this logical ordering. This implies that what was visible to the thread performing step n will be > visible to the thread performing the step n+1, including all memory writes > performed during step n inside stateful transducers. > Only if there is a volatile or lock forcing that visibility. > https://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html > <https://www.google.com/url?q=https%3A%2F%2Fwww.cs.umd.edu%2F~pugh%2Fjava%2FmemoryModel%2Fjsr-133-faq.html&sa=D&sntz=1&usg=AFQjCNFrKhTVAobPzLvc5FHLhtsUgQ5YTg> > > Still no need for extra synchronization. > While this is a good reference, it's also 13 years old and the JMM has been updated since then. A much better reference explaining the semantics and constraints is: https://shipilev.net/blog/2014/jmm-pragmatics/ In particular, even if there is a memory barrier, there are some reorderings allowed if the transducer state is not volatile that may be surprising. Making it volatile adds a critical edge in the total program order. You're conflating the stateful values inside the transducer with the state >> returned by and passed into a transducer. That's a linkage that does not >> necessarily exist. >> > > What do you mean ? How could a function return a value without having > executed its body ? > I'm saying that the logical ordering of steps is irrelevant wrt how a multi-threaded program can be optimized/reordered under the JMM. -- 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.
