Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Inserting In a List

Reply
Thread Tools

Inserting In a List

 
 
Eric Sosman
Guest
Posts: n/a
 
      04-04-2013
On 4/3/2013 10:17 PM, markspace wrote:
> On 4/3/2013 6:20 PM, Eric Sosman wrote:
>> I'm with Arne. The cited section uses the word "immutable"
>> and "immutability" without defining either. All it says is that
>> "final" can be an aid to implementing immutable objects -- but it
>> never says what "immutable" is.

>
> Well, it does. Section 17.5 has several subsections, and it's defined
> in section 17.5.1. I feel one really should read all of 17.5 to
> understand final fields however.


Ah, this is obviously some strange usage of the word "defined"
that I wasn't previously aware of.

Section 17.5.1 ("Semantics of final fields") contains precisely
zero occurrences of the word "immutable," zero occurrences of the
word "mutable," and zero occurrences of the sequences "immu" and
"mut." It's a pretty odd definition that doesn't point out the
term being defined.

>> It doesn't even say that "final"
>> confers immutability; on the contrary, it says "final fields must
>> be *used correctly* [emphasis mine] to provide a guarantee of
>> immutability."

>
> OK, that might be part of the problem. final is necessary but not
> sufficient. I'll concede that, no problem. I misspoke if I implied
> otherwise.


Elsethread you will find demonstrations by various people
that "final" is not necessary for immutability. (Of course,
they're using their own, informal notions of "immutability,"
since the JLS doesn't define one. Perhaps the widely-held
ideas about "immutable" are not those you share.)

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
 
 
 
Joerg Meier
Guest
Posts: n/a
 
      04-04-2013
On Wed, 03 Apr 2013 21:30:16 -0700, markspace wrote:

> On 4/3/2013 8:45 PM, Lew wrote:
>> The word "immutable" is apparently to be understood in its common
>> computer-science meaning.

> Section 17.5 says this in its second paragraph:


> "final fields must be used correctly to provide a guarantee of
> immutability."


I would argue that to mean "If you use final incorrectly, you might still
not have an immutable object" and not "You can only make immutable objects
with use of final".

>> And if you follow the rules of thread-safe immutability, and I don't
>> know how you would dodge them for 'String', threads will never see
>> 0.

> ??? The first thread to calculate a hash code will always see 0.
> That's what triggers the hash code calculation, rather than just
> returning the value stored in the hash code field.


How would that thread see 0 ? When I use String.hashCode for the first
time, I get the hashCode, not 0. The 0 is only ever used internally. Nobody
gets to see it. That's why String is considered immutable.

Liebe Gruesse,
Joerg

--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.
 
Reply With Quote
 
 
 
 
Joerg Meier
Guest
Posts: n/a
 
      04-04-2013
On Wed, 03 Apr 2013 17:19:17 -0700, markspace wrote:

> On 4/3/2013 4:57 PM, Joerg Meier wrote:
>> That initial write is not synchronized to other threads.

> Yes it is! (Not immediately synchronized, at the end of the ctor.)
> Read the JLS, besides the part I quoted above:


I don't read that (or anything relating to threads at all) from that part
of the JLS (other than the mention to the unrelated deref chain).

> That's as clear as mud, but what it means is that objects referenced by
> final fields, and all writes to those objects, are made visible at the
> end of the object's ctor.


Yes, but that is not a multi-threading concern (and in fact writes are also
made visible when the ctor exits on non-final fields).

>> If I misunderstood, and you believe that structural changes to the
>> ArrayList would be visible to all threads, then you are still wrong,

> In the second example you gave where the reference to 'stooges' leaves
> the enclosing class, it is definitely neither immutable nor thread-safe.


>> The mere use of final does not remove the need for synchronization.

> Yes it does! That was explicitly stated in the very short bit I quoted
> at the beginning of this whole mess.


So then my second example, which you just admitted is not thread-safe
above, would by your logic still need no synchronization, because it uses
final. I'm sorry, but that just makes no sense.

You have to decide:

a) the mere use of final does not remove the need for synchronization
b) the mere use of final does remove the need for synchronization, and the
class that exposes the final instance of the list is still thread-safe.

You can't have it both ways.

>> Nor
>> does the mere lack of it dictate a need.

> No. 'final' is special here.


But you can still have immutable, thread safe objects without final:

public class A {
private int i = 1;

public int getI(); { return i; }
}

This class is thread safe and immutable. And completely without final.

>> The reason synchronization is not
>> needed with proper immutability is an effect from what final does - because
>> it can only be assigned once, once it is you can then let everyone play
>> with it, because you dont NEED to worry about writes - there will be none.

> No, you still need to, at a low level, insert a memory barrier to make
> those writes visible.


That memory barrier is the ctor. It alone is enough to make the writes
visible.

> You'd need to use synchronization or a volatile
> variable or some other synchronization in Java, or you could see a
> partially constructed object.


I would like to see an example to back up this claim that it's poissible to
see a partially constructed object merely by it having non-final fields,
without giving out a reference to the partially constructed object (like I
did in my example).

> Also, go read Java Concurrency in Practice by Brian Goetz. He covers
> this in some detail (complete with Stooges example).


Luckily someone else already quoted the point I'm trying to make that you
disagree with: you can have immutable objects without everything being
final just fine, as long as you don't let that lack of finality escape out
into the wild.

Liebe Gruesse,
Joerg

--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.
 
Reply With Quote
 
Joerg Meier
Guest
Posts: n/a
 
      04-04-2013
On Thu, 4 Apr 2013 01:55:43 -0700 (PDT), (E-Mail Removed) wrote:

> Interestingly, is "ThisIsImmutable" immutable given you can do this?


> public class NowItIsnt extends ThisIsImmutable {
> public String getCantChangeMe() {
> return Integer.toString(new Random().nextInt());
> }
> }


> Of course you could make ThisIsImmutable final.


I faced the same question (whether or not to make my example final)
elsethread, but in the end, with Reflection and such, you really aren't
protected against someone trying to intentionally make something mutable.
Between cloning, deserializing, using Reflection to outright remove final
decorations, and the good old brute force method of changing the source
(and you can even override the JCL if you put things in java* packages),
there's a lot of ways to 'break' things if you wanted to.

Writing a super defensive class to protect against all that didn't seem
worth the trouble to make the point we tried to make.

Liebe Gruesse,
Joerg

--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.
 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      04-04-2013
On 4/4/2013 5:27 AM, Eric Sosman wrote:
> Perhaps the widely-held
> ideas about "immutable" are not those you share.)
>


Well, if we're all using different definitions of a term, talking about
it is pretty tough. Immutability is defined correctly in the JLS, at
least for Java. I think it would be most useful to use that term.


 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      04-04-2013
On 4/4/2013 5:34 AM, Joerg Meier wrote:

> How would that thread see 0 ? When I use String.hashCode for the first
> time, I get the hashCode, not 0. The 0 is only ever used internally.


That's what I mean though. Internally, your thread sees 0, and then
calculates the value and caches it. There's nothing magic about
crossing a method boundary. It's all just a stream of machine
instructions to your thread. Visibility of fields (as section 17.4 of
the JLS uses that term) isn't affect by methods or objects unless you do
something explicitly (like use the synchronized keyword).


 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      04-04-2013
On 4/4/2013 5:35 AM, Joerg Meier wrote:

> You have to decide:
>
> a) the mere use of final does not remove the need for synchronization
> b) the mere use of final does remove the need for synchronization, and the
> class that exposes the final instance of the list is still thread-safe.
>


I thought it was obvious, but of course you also have to prevent writes
to the object. final is necessary but not sufficient. Mea culpa if
that's the cause of the misunderstanding here. I should have been more
precise in my language. Unfortunately I was just focusing on one aspect
of making an object immutable, just the final-ctor combo, and ignoring
others.

> But you can still have immutable, thread safe objects without final:
>
> public class A {
> private int i = 1;
>
> public int getI(); { return i; }
> }
>
> This class is thread safe and immutable. And completely without final.


No, this is very explicitly wrong, and I'm sure the rest of the list
would agree. (I think you're confusing this with an example using a
static (class) field.)

The JLS explicitly says that writes on one thread are not visible
immediately to another thread. If thread A constructs this object, then
thread B calls getI, it's liable to see the previous value of i (0)
rather than the write by thread A which is still sitting in A's CPU cache.

You have to do something to flush that write out to main memory. In a
nutshell, that's what visibility means in the JLS. Two threads on two
CPUs won't see the same values unless force those writes to flush out to
main memory.

>
> That memory barrier is the ctor. It alone is enough to make the writes
> visible.


No, memory barriers are pretty expensive and the Java compiler doesn't
force them when not needed. Regular ol' POJO objects don't have a
memory barrier at the end of their ctor. That's the whole point of
section 17 in the JLS, Threads and Locks. It tells you how to use your
normally not-thread-safe objects safely.

> I would like to see an example to back up this claim that it's poissible to
> see a partially constructed object merely by it having non-final fields,
> without giving out a reference to the partially constructed object (like I
> did in my example).


There are several good examples in the JLS, which I'm going to refer you
too, so I don't louse-up an example again. There's example 17.4-1 in
the section on the Java memory model:

<http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4>

There also another example 17.4.5-1 in the section on happens-before
consistency

<http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.5>

Both of those examples involve two writes, but that doesn't matter. The
accompanying text makes it clear that any write, even one single write,
can be re-ordered by the system.

Also take a look at section 17.4.1 where it talks about shared variables
and heap memory.

<docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.1>

Instance fields are explicitly included, and your class A has an
instance field i that needs to be synchronized somehow. It's not thread
safe on its own.

> Luckily someone else already quoted the point I'm trying to make that you
> disagree with: you can have immutable objects without everything being
> final just fine, as long as you don't let that lack of finality escape out
> into the wild.


That example was really different than what you presented in your
example with the class A above. It's one reason why Arne's example from
JCIP also says "don't try this at home." It's really tough to
reason about these things and easy to get wrong; really really easy. I
urge you to study this because I'm concerned that you've missed a couple
of not-too-subtle points about concurrency in Java.


 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      04-04-2013
On 04.04.2013 06:30, markspace wrote:
> On 4/3/2013 8:45 PM, Lew wrote:
>> markspace wrote:
>>> Eric Sosman wrote:


>> Section 17.5, however, does define "thread-safe immutable":

> ...
>> The word "immutable" is apparently to be understood in its common
>> computer-science meaning.

>
> Section 17.5 says this in its second paragraph:
>
> "final fields must be used correctly to provide a guarantee of
> immutability."
>
> That's the last sentence. To me that's ascribing special semantics to
> just the word 'immutable.' If it's saying "final fields must be used"
> then it's special for final fields. I realize there a qualifier on
> that, but the qualifier is "correctly" and they're just pointing out
> it's a little tricky. final fields must be used is the key point.
> (Used incorrectly, of course, they won't guarantee immutability.)


The sentence states that you will only get immutability if you use final
fields correctly. That does not imply that final fields are necessary
to achieve immutability. For at least one definition of "immutable" you
can create classes with no setters and getters only returning immutable
objects - without ever using the keyword "final".

> I see how you might read that differently, but without final fields the
> number of useful immutable classes is pretty small. (I'm ignoring
> stateless objects here.)


Not at all.

Kind regards

robert


--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      04-04-2013
On 4/4/2013 10:44 AM, Robert Klemme wrote:
> On 04.04.2013 18:47, markspace wrote:
>> On 4/4/2013 5:27 AM, Eric Sosman wrote:
>>> Perhaps the widely-held
>>> ideas about "immutable" are not those you share.)

>>
>> Well, if we're all using different definitions of a term, talking about
>> it is pretty tough. Immutability is defined correctly in the JLS, at
>> least for Java. I think it would be most useful to use that term.

>
> If it was I'd guess the terms "mutable" or "immutable" would surely show
> up in the index, but they don't - opposed to "final" which has several
> entries:
>
> http://docs.oracle.com/javase/specs/...s-0-index.html
>
> No, the JLS does not define "immutable" - it just mentions it.


OK then, so what definition would this group like to use to describe the
kinds of objects the JLS talks about in Section 17.5?



 
Reply With Quote
 
Jim Janney
Guest
Posts: n/a
 
      04-04-2013
markspace <(E-Mail Removed)> writes:

> On 4/3/2013 5:10 PM, Arne Vajh?j wrote:
>>
>> It can be very important in multithreaded context.
>>
>> But it is not what makes a class immutable.

>
> OK, that's true. The section I linked to refers to such objects as
> "thread safe immutable." It's both concepts in one package. Objects
> that aren't thread safe aren't immutable, and objects that aren't
> immutable aren't thread safe. I guess that's why the two go together.


Immutable objects don't need to be defensively copied. This can be
useful even in situations where thread safety doesn't apply.

--
Jim Janney
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Inserting into DB table with date from Generic List =?Utf-8?B?U3Jpbmk=?= ASP .Net 0 11-07-2006 04:33 AM
inserting into a list John Salerno Python 15 03-08-2006 06:02 AM
Linked list inserting items from two different funcion Kay C++ 1 09-03-2004 03:48 PM
Urgent:Inserting records from datagrid through drop down list Muhammad Usman ASP .Net 1 10-16-2003 01:39 PM
Inserting an empty element in a list (STL) Massimiliano Alberti C++ 3 09-24-2003 05:48 PM



Advertisments