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 
<https://github.com/clojure/clojure/blob/c0326d2386dd1227f35f46f1c75a8f87e2e93076/src/clj/clojure/core.clj#L4940>)
 
to ensure memory visibility. This usage of volatile is actually the 
original motivation <http://dev.clojure.org/jira/browse/CLJ-1512> for 
adding it in core, and is explained further here 
<http://stackoverflow.com/questions/31288608/what-is-clojure-volatile> and 
here <http://insideclojure.org/2014/12/17/distinct-transducer/>.
However, some stateful tranducers use unsynchronized mutable state instead 
(e.g partition-all 
<https://github.com/clojure/clojure/blob/c0326d2386dd1227f35f46f1c75a8f87e2e93076/src/clj/clojure/core.clj#L7123>),
 
which goes against the previous volatile argument of "safely publish values 
between threads".
In practice, partition-all works fine in e.g core.async because each call 
to the (maybe stateful) step function is made inside the channel lock.

So my question is, does it make any sense at all to have a transducing 
context that does *not* enforce a *happens-before* order between successive 
calls to the step function ?
If yes, I would be curious to see an example, and that would mean 
partition-all is broken.
If no, what is the point of using volatiles for stateful transducers ? As 
long as they are not exposed to the outside, unsynchronized variables would 
do the job and should be slightly faster.

Am I missing something ?
Thanks

Leo

-- 
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.

Reply via email to