Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

Inserting In a List

 
 
Robert Klemme
Guest
Posts: n/a
 
      04-04-2013
On 04.04.2013 20:08, markspace wrote:
> 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?


I'd go with the heading of that section: "final Field Semantics" - and
it's not primarily about "objects" but about "final fields" or put
differently: final object references. That section defines semantics of
final fields and just mentions "immutable objects" as an example of a
concept that may be created by (properly) using final fields.

Immutability (or constness) of an object is a tricky concept. There are
at least two useful and totally reasonable definitions:

1. State (as in: bit patterns in memory) of a const object never changes.

2. The user of a const object can never observe any state changes; put
differently: all methods of a constant object always return the same
results for the same inputs.

You can also see that from the development C++ took: keyword "mutable"
was introduced later to allow state changes of instances declared
"const"; this helps implementing lazy initialization and caching schemes.

Other than for type 1 constness compiler checks for type 2 constness are
significantly more complicated - if they are possible at all: call a
function in a method and all bets are off. Without access to the
function's source (or at least bytecode in Java) a compiler cannot
determine whether type 2 constness is observed in all circumstances.

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 1:53 PM, Robert Klemme wrote:
> Immutability (or constness) of an object is a tricky concept. There are
> at least two useful and totally reasonable definitions:
>
> 1. State (as in: bit patterns in memory) of a const object never changes.
>
> 2. The user of a const object can never observe any state changes; put
> differently: all methods of a constant object always return the same
> results for the same inputs.


How about #3: thread-safe immutable?

That that might be the same as #2, but I wouldn't be willing to swear it
is in all cases.

>
> You can also see that from the development C++ took: keyword "mutable"


I think it's a mistake to conflate Java with other languages.


 
Reply With Quote
 
 
 
 
Joerg Meier
Guest
Posts: n/a
 
      04-04-2013
On Thu, 4 Apr 2013 21:47:00 +0000 (UTC), Martin Gregorie wrote:

> On Thu, 04 Apr 2013 14:12:35 +0200, Joerg Meier wrote:
>> What ? Is this CS first semester homework or something ?

> My guess is that its exactly that.


I took you to be talking about things at your work place or whatever.

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, 04 Apr 2013 09:52:11 -0700, markspace wrote:

> 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).


Then we (or you and Lew) don't disagree - we were talking about different
things. We were talking about the fact that the internal 'state' of String
is not visible to the outside (as in to a calling class), even in
multi-threading.

Liebe Gruesse,
Joerg

--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.
 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      04-04-2013
On 04/04/2013 06:20 AM, Stefan Ram wrote:
> Arved Sandstrom <(E-Mail Removed)> writes:
>> I would say that the *array* of char is mutable.

>
> An array of chars is not an array of char values,
> but of char variables, each of which is mutable.
>

That doesn't follow, not for me. We say that something, like an object,
is mutable when the contents of it can be changed. Each one of those
elements - char variables as per the JLS - points to an immutable thing:
how are they mutable? It is the container object - in this case the
array - which is mutable.

I still stand by my opinion that variables are not what you consider to
be mutable or immutable. It's what they point to.

AHS
 
Reply With Quote
 
Joerg Meier
Guest
Posts: n/a
 
      04-04-2013
On Thu, 04 Apr 2013 10:34:59 -0700, markspace wrote:

I deleted the rest of your post, as it comes down to this:

> On 4/4/2013 5:35 AM, Joerg Meier wrote:
>> 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 was under the impression that, well, what I said above was correct. If
it's not, the rest of my argument collapses like a house of cards. I'm
going to have to put in some more research as I'm not just going to take
your word for it, but for now it seems I was wrong.

Thanks for the links, I will peruse them at a more civilized hour. It's
been a long time since i read jcip, so maybe I should dig that up again as
well - has that been updated any in the past years, or can I make due with
my old copy ?

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 3:43 PM, Joerg Meier wrote:
> On Thu, 04 Apr 2013 10:34:59 -0700, markspace wrote:
>
> I deleted the rest of your post, as it comes down to this:
>
>> On 4/4/2013 5:35 AM, Joerg Meier wrote:
>>> 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 was under the impression that, well, what I said above was correct. If
> it's not, the rest of my argument collapses like a house of cards.



Yes, and obviously the same for my argument.

I don't think JCIP has changed or been updated. I don't think you have
to review the whole thing either, just the section where he talks about
making objects immutable. Page 47 is the crux of the matter, I believe.



 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      04-04-2013
Joerg Meier wrote:
> markspace wrote:
> I deleted the rest of your post, as it comes down to this:
>> Joerg Meier wrote:
>>> 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 was under the impression that, well, what I said above was correct. If
> it's not, the rest of my argument collapses like a house of cards. I'm
> going to have to put in some more research as I'm not just going to take
> your word for it, but for now it seems I was wrong.
>
> Thanks for the links, I will peruse them at a more civilized hour. It's
> been a long time since i read jcip, so maybe I should dig that up again as
> well - has that been updated any in the past years, or can I make due with
> my old copy ?


http://docs.oracle.com/javase/specs/...tml#jls-17.4.5
"Two actions can be ordered by a happens-before relationship. If one action
happens-before another, then the first is visible to and ordered before thesecond."

The only mention of constructors is:
"There is a happens-before edge from the end of a constructor of an object to the
start of a finalizer (?12.6) for that object."

The trick is to do what you need to do before spawning the additional thread(s):
"If x and y are actions of the same thread and x comes before y in program order, then hb(x, y)."
"A call to start() on a thread happens-before any actions in the started thread."

So don't start threads from within a constructor.

This follows from the advice not to do anything but construction within a constructor.

--
Lew
All rules should be broken occasionally, including this one.
No rules should ever be broken, except this one.


 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      04-05-2013
On 4/4/2013 4:49 PM, Lew wrote:
> Joerg Meier wrote:
>> markspace wrote:
>> I deleted the rest of your post, as it comes down to this:
>>> Joerg Meier wrote:
>>>> 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 was under the impression that, well, what I said above was correct. If
>> it's not, the rest of my argument collapses like a house of cards. I'm
>> going to have to put in some more research as I'm not just going to take
>> your word for it, but for now it seems I was wrong.
>>
>> Thanks for the links, I will peruse them at a more civilized hour. It's
>> been a long time since i read jcip, so maybe I should dig that up again as
>> well - has that been updated any in the past years, or can I make due with
>> my old copy ?

>
> http://docs.oracle.com/javase/specs/...tml#jls-17.4.5
> "Two actions can be ordered by a happens-before relationship. If one action
> happens-before another, then the first is visible to and ordered before the second."
>
> The only mention of constructors is:
> "There is a happens-before edge from the end of a constructor of an object to the
> start of a finalizer (?12.6) for that object."


There's also several mentions in 17.5.1 final Field Semantics:

"Let o be an object, and c be a constructor for o in which a final field
f is written. A freeze action on final field f of o takes place when c
exits, either normally or abruptly." And a few other mentions following
that.

The "freeze action" is later in that section explained to work like a
happens-before relation.

"Given a write w, a freeze f, an action a (that is not a read of a final
field), a read r1 of the final field frozen by f, and a read r2 such
that hb(w, f), hb(f, a), mc(a, r1), and dereferences(r1, r2), then when
determining which values can be seen by r2, we consider hb(w, r2). (This
happens-before ordering does not transitively close with other
happens-before orderings.) "

It's a wee bit complicated to suss out, but I do believe it is saying
that final fields are special in that they create happens-before
relationships that don't exist for fields that are non-final. That goes
for private fields, public fields, etc. Only final fields get this
freeze action with the happens-before relationship.




 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      04-05-2013
markspace wrote:
> There's also several mentions in 17.5.1 final Field Semantics:
>
> "Let o be an object, and c be a constructor for o in which a final field
> f is written. A freeze action on final field f of o takes place when c
> exits, either normally or abruptly." And a few other mentions following
> that.
>
> The "freeze action" is later in that section explained to work like a
> happens-before relation.
>
> "Given a write w, a freeze f, an action a (that is not a read of a final
> field), a read r1 of the final field frozen by f, and a read r2 such
> that hb(w, f), hb(f, a), mc(a, r1), and dereferences(r1, r2), then when
> determining which values can be seen by r2, we consider hb(w, r2). (This
> happens-before ordering does not transitively close with other
> happens-before orderings.) "
>
> It's a wee bit complicated to suss out, but I do believe it is saying
> that final fields are special in that they create happens-before
> relationships that don't exist for fields that are non-final. That goes
> for private fields, public fields, etc. Only final fields get this
> freeze action with the happens-before relationship.


For the purposes of this thread, this is pretty much the capper on the
usefulness of 'final' for thread safety.

It confirms that 'final' is not just window dressing, and that its semantics
are tightly tied to creating thread-safe code.

It also confirms that the JLS is incredibly important to correct Java programming.

Thanks for citing that.
--
Lew
 
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