Thanks for clearing all of that up Alex! Very helpful. On Monday, April 10, 2017 at 3:46:45 PM UTC-4, Alex Miller wrote: > > > > On Monday, April 10, 2017 at 2:25:48 PM UTC-5, Alexander Gunnarson wrote: >> >> I think you present a key question: what assumptions can a transducer >> make? We know the standard ones, but what of memory barriers? >> > > Transducers should ensure stateful changes guarantee visibility. That is: > you should not make assumptions about external memory barriers. > > >> Based on the current implementation, in terms of concurrency, it seems to >> make (inconsistent — see also `partition-by`) guarantees that sequential >> writes and reads will be consistent, no matter what thread does the reads >> or writes. Concurrent writes are not supported. But *should *sequential >> multi-threaded reads/writes be supported? >> > > Yes. core.async channel transducers already do this. > > >> This is a question best left to Alex but I think I already know the >> answer based on his conversation with Rich: it's part of the contract. >> >> I think another key question is, is the channel lock memory barrier part >> of the contract of a core.async channel implementation? >> > > Yes, but other transducing processes may exist either in core in the > future or in external libs. > > >> If not, volatiles will be necessary in that context if the memory barrier >> is ever taken away, and it would make sense that volatiles are used in >> transducers "just in case" specifically for that use case. But if the >> channel lock memory barrier *is* part of the contract and not just an >> implementation detail, then I'm not certain that it's very useful at all >> for transducers to provide a guarantee of safe sequential multi-threaded >> reads/writes. >> >
-- 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.
