Yep. PersistentVector is *mutable* per the JCIP definition. If it is *mutable* then you need to use locks or synchronization to access its contents.
If your program doesn't modify its the vector, it is *effectively immutable. *But, you need to ensure that you safely publish it. But, if you create a PersistentVector, and somehow ensure that the array's contents are never modified, you can pass it freely between threads without synchronization. In short, even though you can't claim that PersistentVector is *immutable*, if you discipline yourself on how you use it, you can pretend that it is. This is a consequence of the use of final on the array field in PersistentVector. On Wednesday, May 7, 2014 10:17:38 AM UTC-4, Andy Fingerhut wrote: > > Mike, I believe I understand the definition of "truly immutable" you are > using here, and what it means in the JVM as far as synchronization of > object values across threads. > > What seems a bit odd is to use the phrase "truly immutable" to describe > something that is clearly mutable, or at least it is by the definition of > "mutable": "can be modified after construction", which PersistentVector and > others can be. > > Thanks, > Andy > > > On Tue, May 6, 2014 at 6:20 PM, Mike Fikes <mike...@me.com > <javascript:>>wrote: > >> Hi Andy, >> >> Marking Java fields as final has semantics with respect to threading, >> defined in the JLS in section 17.5 ( >> http://docs.oracle.com/javase/specs/jls/se5.0/html/memory.html#17.5) >> >> If you do this, then it makes it possible to freely pass a "truly" >> immutable object instance to another thread and be guaranteed that that >> other thread will see the value initialized for that field in the >> constructor. >> >> If you don't do this, then the object can still be "effectively" >> immutable, which essentially means that you can pass the object to another >> thread, so long as you do it in a safe manner (using a volatile, or some >> synchronization mechanism). >> >> JCIP helps clarify all of this unfortunately complex topic. >> >> The important thing (and key to Closure), is that, if you are >> implementing the class that you want to be immutable, then if you can mark >> everything as final, then you truly achieve the benefits immutability give >> you with concurrency (in short, you need no synchronization whatsoever). If >> you fail to do this, then you have "effective" immutability, which is good, >> but complex and comes with caveats on how you can safely pass objects >> between threads. >> >> JCIP is a great book. But, the approach taken by Clojure makes a lot of >> the complicated concerns covered by the book largely ignorable, IMHO. >> >> On Tuesday, May 6, 2014 8:35:43 PM UTC-4, Andy Fingerhut wrote: >> >>> Alex, I may be unfamiliar with the definitions of truly immutable and >>> effectively immutable being used here, but if I can mutate the contents of >>> a Java Object array that is a final field after an object is constructed, >>> does it really matter that much if it is final? It is trivially easy to >>> mutate using Java access. Here is the example that I mentioned earlier in >>> this thread, copied here for convenience: >>> >>> user=> (def v [1 2 3]) >>> #'user/v >>> user=> (class v) >>> clojure.lang.PersistentVector >>> user=> v >>> [1 2 3] >>> user=> (aset (.tail v) 1 -2) >>> -2 >>> user=> v >>> [1 -2 3] >>> >>> Andy >>> >>> >>> On Tue, May 6, 2014 at 4:49 PM, Alex Miller <al...@puredanger.com>wrote: >>> >>>> The Clojure persistent data structures are truly immutable - all >>>> fields are final and referred objects are not mutated after construction >>>> so >>>> that freeze occurs. One obvious exception are the transient variants ( >>>> http://clojure.org/transients). You can look at the code in >>>> https://github.com/clojure/clojure/tree/master/src/jvm/clojure/lang - >>>> any of the Persistent*.java. >>>> >>>> >>>> On Tuesday, May 6, 2014 4:11:49 PM UTC-5, Mike Fikes wrote: >>>>> >>>>> Are the persistent immutable data structures in Clojure "truly" >>>>> immutable (using final fields, relying on constructor freezing), or are >>>>> they mean to be merely effectively immutable (as defined in JICP)? >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Clojure" group. >>>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com. >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com<javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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.
