It will also see versions of any object or array referenced by those
final fields that are **at least as up-to-date as the final fields**
are.
To me this means that the value of the final field will be correctly
published **as of the time it was assigned**. So in your example,
there are two
immutable (Objects that are not technically
immutable, but whose state will not be modified after publication),
PersistentVector appears to me to be effectively immutable, but not truly
immutable.
Andy
On Tue, May 6, 2014 at 8:31 PM, Alex Miller al...@puredanger.com wrote:
Hey Andy,
It does
In the sample code I pasted, there is nothing to prevent the fill(1) and
fill(2) from running concurrently, and essentially write into the same array
concurrently. My intent was that the fill(1) be complete before the second
thread proceeds.
A simple change to have the 1st thread instead fill
Alexandru Nedelcu a...@bionicspirit.com writes:
On Wed, May 7, 2014 at 5:57 PM, Phillip Lord
phillip.l...@newcastle.ac.ukwrote:
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
Thanks Alexandru! That was insightful. :)
Even the JLS's (non-normative?) text is confusing IMHO. Section 17.5 ends
with this paragraph:
The usage model for final fields is a simple one. Set the final fields for
an object in that object's constructor. Do not write a reference to the
object
On Wed, May 7, 2014 at 6:31 AM, Alex Miller a...@puredanger.com wrote:
It does matter with regard to visibility across threads - your example does
not use a synchronization mechanism and there is no guarantee that other
threads will ever see those changes (so don't ever ever do that :). But if
On Wed, May 7, 2014 at 5:57 PM, Phillip Lord
phillip.l...@newcastle.ac.ukwrote:
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
Since the data structures and interfaces, they are effectively
immutable.
Consider this:
final public class Cons extends ASeq implements Serializable {
private final Object _first;
private final ISeq _more;
public Cons(Object first, ISeq _more){
this._first = first;
this._more
.
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
during construction).
I have no argument with PersistentVector satisfying the 2nd and 3rd bullet
points above, but (1) seems not to hold. According to JCIP's definition of
effectively immutable (Objects that are not technically immutable, but
whose state will not be modified after publication
Phil, that's an interesting point.
Consider (def x (cons (new java.util.Date) ()))
The object identified by x is *mutable*, but if the contained Date will not
be modified by the program, then the resulting object can be treated as
*effectively
immutable, *as you pointed out.
But, it would
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
* (the 'this' reference does not escape
during construction).
I have no argument with PersistentVector satisfying the 2nd and 3rd bullet
points above, but (1) seems not to hold. According to JCIP's definition of
effectively immutable (Objects that are not technically immutable, but
whose state
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
I haven't read JICP that you refer to, but I believe that they are
effectively immutable.
See a post by me in this thread titled Clojure Concurrency and Custom
Types from March 2013 for how to stay within Clojure, but I believe
requiring Java interop calls, to mutate in place Clojure's immutable
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 clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post
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
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
2014 02:35, Andy Fingerhut andy.finger...@gmail.com 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
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
ArrayNode is
effectively immutable but also safely published by any truly immutable data
structures by being referred to in final fields.
Excellent! I had to look for myself, and now I feel much more comfortable
that Clojure is built upon the bedrock it needs to be :)
On Tuesday, May 6, 2014 7
), 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 clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
/11/26/jmm-and-final-field-freeze/
Alex
On Tuesday, May 6, 2014 7:35:43 PM UTC-5, 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
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.comjavascript:
Note that posts from new members are moderated - please be patient
24 matches
Mail list logo
