I don't agree with your conclusions. :) A transducing process could apply each step of the transduce using a thread from a pool and also not use a memory barrier - in that scenario visibility across threads would not be ensured. These kinds of failures are inherently difficult to reproduce unless the code is in production and you're on vacation. ;)
On Monday, April 10, 2017 at 8:37:29 AM UTC-5, Léo Noel wrote: > > This topic is of high interest to me as it is at the core of my current > works. I had a similar questioning a while ago > <https://groups.google.com/forum/#!topic/clojure/2WtfyLG2Jls> and I have > to say I'm even more confused with this : > > While transducing processes may provide locking to cover the visibility of >> state updates in a stateful transducer, transducers should still use >> stateful constructs that ensure visibility (by using volatile, atoms, etc). >> > > I actually tried pretty hard to find a use case that would make > partition-all fail because of its unsynchronized local state, and did not > manage to find one that did not break any contract. I arrived at the > conclusion that it is always safe to use unsynchronized constructs in > stateful transducers. The reason is that you need to ensure that the result > of each step is given to the next, and doing so you will necessarily set a > memory barrier of some sort between each step. Each step happens-before the > next, and therefore mutations performed by the thread at step n are always > visible by the thread performing the step n+1. This is really brilliant : > when designing a transducer, you can be confident that calls to your > reducing function will be sequential and stop worrying about concurrency. > You just have to ensure that mutable state stays local. True encapsulation, > the broken promise of object-oriented programming. > > My point is that the transducer contract "always feed the result of step n > as the first argument of step n+1" is strong enough to safely use local > unsynchronized state. For this reason, switching partition-* transducers to > volatile constructs really sounds like a step backwards to me. However, > after re-reading the documentation on transducers, I found that this > contract is not explicitly stated. It is just *natural* to think this way, > because transducers are all about reducing processes. Is there a plan to > reconsider this principle ? I would be very interested to know what Rich > has in mind that could lead him to advise to overprotect local state of > transducers. > -- 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.
