Inserting In a List

R

Robert Klemme

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
 
M

markspace

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

Joerg Meier

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
 
A

Arved Sandstrom

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
 
J

Joerg Meier

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
 
M

markspace

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

Lew

Joerg said:
markspace wrote:
I deleted the rest of your post, as it comes down to this:


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/jls/se7/html/jls-17.html#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.
 
M

markspace

http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#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.
 
L

Lew

markspace said:
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.
 
S

Stefan Ram

Arved Sandstrom said:
Each one of those elements - char variables as per the JLS -
points to an immutable thing

We do not use ?point? for variables of primitve types like
?char?. A variable ?has? a value.
: how are they mutable?

By an assignment, like ?a[ 5 ]= 8?.
It is the container object - in this case the array - which
is mutable.

JLS7: ?An array object contains a number of variables.?,
?A variable is a storage location?.
 
A

Arved Sandstrom

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.
This thread, and material like the above, also confirms that 99 percent
of us, yours truly included, would do best to (1) have a copy of JCIP
and regularly read it, and (2) be intimately familiar with the
high-level concurrency classes and use those in preference to low-level
stuff.

I have followed both of these recommendations for years now. I simply do
not have the time anymore - have not had it for many years - to stay on
top of low-level Java concurrency at an expert level. And my personal
belief is that with concurrency you can't just be OK, you need to be
very proficient with the tools you choose to use. JCIP and the
high-level classes give that large majority of us the ability to master
concurrency programming in Java.

AHS
 
A

Arved Sandstrom

We do not use ?point? for variables of primitve types like
?char?. A variable ?has? a value.

Who is "we"? And don't get all hung up on my use of the English word
"point", I am not implying an equivalence with C pointers here. In fact
I am making use of the very meaning that you trot out below, that a
variable is a storage location.
: how are they mutable?

By an assignment, like ?a[ 5 ]= 8?.
You are entirely missing my argument. I know there's an English word
"mutable", and I know what it means. My argument is that it would be
seriously helpful if it were not used for *changing the value* of a
variable.
JLS7: ?An array object contains a number of variables.?,
?A variable is a storage location?.
Right. Now step back from trotting out JLS quotes and interpret them,
and also *hear* what I am trying to say. Anyone can quote anything,
doesn't mean they are understanding anything.

AHS
 
S

Stefan Ram

Arved Sandstrom said:
Who is "we"?

All persons in this newsgroup except you.

(I will feel refuted, should anyone /else/ answer now, that
he also would say that after the assignment a[ 5 ]= 'a',
the variable a[ 5 ] ?pointed? to the value 'a'.)
And don't get all hung up on my use of the English word
"point", I am not implying an equivalence with C pointers here.

What is C? We have pointers in Java, see the JLS.
You are entirely missing my argument. I know there's an English word
"mutable"

, and I know what it means. My argument is that it would be
seriously helpful if it were not used for
*changing the value* of a variable.

I agree. The sentence

?I am changing the value of a variable.?

does surely not have the same meaning as

?I am mutable.?
 
R

Robert Klemme

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

I didn't conflate anything. I used features of another language to
illustrate aspects of the concept constness / immutability.

Cheers

robert
 
L

Lew

lipska said:
Stefan said:
Arved said:
Stefan Ram wrote:
Arved Sandstrom writes:
[snip]

What is C? We have pointers in Java, see the JLS.

Do we? I never knew that

It's in the JLS, 4.3.1.
"An object is a class instance or an array.

"The reference values (often just references) are pointers to these objects,
and a special null reference, which refers to no object."
a pointer in C

int x
int *iptr;
iptr = &x;
iptr++; //stupid but not illegal

How would I do that in Java using pointers (note the *pointer arithmatic*).

Java does not have pointer arithmetic.

It only has pointers for reference types, so the nearest equivalents are:

int x;
Integer iptr;
iptr = Integer.valueOf(x);
// no pointer arithmetic
You learn something new every day.

Hopefully.
 
A

Arved Sandstrom

Arved Sandstrom said:
Who is "we"?

All persons in this newsgroup except you.

(I will feel refuted, should anyone /else/ answer now, that
he also would say that after the assignment a[ 5 ]= 'a',
the variable a[ 5 ] ?pointed? to the value 'a'.)

Nobody else may. Doesn't bother me none. Given that you yourself have
made it clear that according to JLS a variable is a storage location,
I'm happy to use the term "point" somewhat informally.
What is C? We have pointers in Java, see the JLS.

Mindful of what Lew said below, can we assume that Java pointers are the
same as C pointers? Well, no, they are not. It's again an example of an
English word being used for similar but not identical concepts.
, and I know what it means. My argument is that it would be


I agree. The sentence

?I am changing the value of a variable.?

does surely not have the same meaning as

?I am mutable.?
To be precise, I'd prefer never to say that a variable is mutable or
immutable. I'd prefer to use those terms to describe what the variable
points to.

AHS
 
R

Robert Klemme

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.

I think there's too much mixed here. "Thread safety" and
"(im)mutability" are two different concepts. They are orthogonal -
albeit related because the latter can help to achieve the former.
Mutability itself is complex as I have tried to show elsewhere in this
thread. Then again thread safety is a much more complex concept.

First of all, objects which are mutable can be thread safe - it depends
on their implementation. (J?rg pointed that out already).

Then: you wrote "Objects that aren't thread safe aren't immutable". Now
this depends on what we mean by "thread safe". An immutable object's
state is guaranteed to be seen by all threads identical (given proper
coding, which might include the use of "final" fields and creation of an
instance before other threads are started OR handing it over to them in
a thread safe manner w.g. with a blocking queue which memory barriers
through its synchronization).

But: that does not necessarily constitute thread safety. An immutable
object can still be implemented in a thread unsafe manner. For example:

public final class KeyValuePairPrinter {
private final PrintStream out;
public KeyValuePairPrinter(PrintStream out) {
this.out = out;
}

/**
* Print a single line with key "=" value.
* @param key key to print before equals sign
* @param value value to print after equals sign
*/
public void print(Object key, Object value) {
out.print(key);
out.print("=");
out.println(value);
}
}

Now, this class is immutable - but is it thread safe? I'd say no,
because there is no guarantee that key, "=" and value are printed on the
same line in a multithreaded environment.
final is required, but you also have to actually prevent any
modification to the object's state after it is constructed. It is a two
part process, that is true.

"final" is neither required nor sufficient for immutability AND thread
safety. For example, as long as you ensure there is a memory barrier
between construction and use of an instance final fields are not needed
to ensure other threads see the proper state. Thread safety usually
cannot be ensured by a single class. The typical example is
Collection.synchronizedMap(): if you use the typical pattern "test if a
key is present and if not add it to the Map" without explicit
synchronization the code is not thread safe even though the Map ensures
it's never modified at the same time by two threads and all threads see
all updates from other threads. There are many more examples like that.

Kind regards

robert
 
R

Robert Klemme

lipska the kat wrote:

Java does not have pointer arithmetic.

It only has pointers for reference types, so the nearest equivalents are:

int x;
Integer iptr;
iptr = Integer.valueOf(x);
// no pointer arithmetic

Albeit: iptr has different semantics than in the C list because it does
not alias the original value. An assignment to x after this line will
go unnoticed by anybody using iptr while in C/C++ it will be noticed.
Well, that's they way it is...

Kind regards

robert
 
R

Robert Klemme

lipska said:
Stefan Ram wrote:
Arved Sandstrom writes:
Stefan Ram wrote:
Arved Sandstrom writes:

[snip]

What is C? We have pointers in Java, see the JLS.

Do we? I never knew that

It's in the JLS, 4.3.1.
"An object is a class instance or an array.

"The reference values (often just references) are pointers to these
objects,
and a special null reference, which refers to no object."

This is a rhetorical usage of the word pointer and says nothing about
the underlying mechanism used to implement references.

Why "rhetorical"? You seem to imply that "pointer" and "memory address"
are synonymous. But this is not necessarily the case even though
personally I tend to also use it that way.

<pssst>I think Lew enjoys it from time to time to prove someone wrong
who claims there are no pointers in Java because it is often surprising
for Java programmers to find that p-word in the JLS. :-) said:
Weasel words, I don't believe that you actually believe that.

Why and why? There is nothing weaselish about quoting the JLS. Do you
have a definition of the Java language with higher authority that does
not contain the word "pointer"?
A reference is an abstraction of a pointer, [...]

I think most people in software engineering actually use the terms the
way you have presented them here which is also reflected in the article
about pointers on wikipedia. That does not preclude other usages in
specific context so the heads up of Lew is actually in order to keep us
alert and use terms consciously.

Kind regards

robert
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top