Re: Usefulness of "final" (Was: Re: Inserting In a List)
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 a=
s
well - has that been updated any in the past years, or can I make due wit=
h
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 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 (=A712.6) for that object."
The trick is to do what you need to do before spawning the additional threa=
d(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 th=
read."
So don't start threads from within a constructor.
This follows from the advice not to do anything but construction within a c=
onstructor.
--
Lew
All rules should be broken occasionally, including this one.
No rules should ever be broken, except this one.