On Wed, May 7, 2014 at 5:57 PM, Phillip Lord <phillip.l...@newcastle.ac.uk>wrote:
> In general, though, if I write some code like > > (if (instance? Cons x) > (pass-to-another-thread-without-synchronisation x)) > > I cannot guarantee the result of this because although I know that > the head of x is fixed, I cannot guarantee that for the tail. If I know > how x is constructed, of course, then I can make this guarantee. > On the other hand, that's not the concern of the piece of code you outlined. Because if "x" wasn't constructed properly and the "latest" data in it is not visible, there's absolutely nothing you can do about it ;-) Visibility is (or should be) the concern of the producer, not of the consumer. > You get the a related problem in Java. > > List l = Collections.unmodifiedableList(l); > > Is l now unmodifiable? Well maybe, depending on what happened to it > before. > What happened to it "before" is not relevant, because again, there's nothing you can do about it at this point and actually from this consumer's perspective "before" doesn't exist ... there's only "now" with the only question being if there are or there will be pending changes that may or may not be published in the future (where "future" is kind of thread-local). Concurrency is hard, but it's greatly simplified if you keep the concerns for atomicity and visibility on the producer's side. And if some third-party module or function or class or whatever doesn't respect this rule by delegating such concerns to the consumer, then simply scrap it from the code-base if it's such a big deal - Date is mutable and that's a problem? Use Joda, etc... Java libraries also document when something is thread-safe and if that's left unspecified, it means that it isn't. That's how people working with C++ also keep their sanity in regards to memory management - i.e. when a producer passes along a pointer or reference of something to a consumer, the sanest thing to do is to consider deallocation or other life cycle issues as the responsibility of the producer, unless it's very explicit in the exposed API that the consumer should handle it. -- Alexandru Nedelcu www.bionicspirit.com PGP Public Key: https://bionicspirit.com/key.aexpk -- 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.
