Are Java Object References atomic?
Stephen Tenberg
I have a background thread in a servlet that uses a traditional (hand-coded)
doubly linked list, using data elements and forward and backward pointers
(sorry, object references, I got carried away when my old C++ linked list
routine converted to java with such a couple of syntax changes).
The background thread does some database stuff occasionally, and
periodically updates the linked list by either appending or removing links.
Meanwhile, the user threads retrieve data from the linked list as users
request it; always the entire list is scanned.
Originally I wrote everything to use java synchronization so that users
can't retrieve inconsistent data, but now I am not so sure its needed.
Since I build a new link first, and then link it last, there is only one
class reference updated, in other words, the codes says:
last_object.next_link = created_object
So the question, is, are java object references atomic? Is this guaranteed
to be completed in an interruptible instruction. I have read that java does
make this guarantee for 32 bit integers, but *not* for 64 bit ones. However
that article was talking about data.
For that matter, are java references 32 bits on most platforms?
Steve
Patricia Shanahan
http://java.sun.com/docs/books/jls/html/17.doc.html#28654, and also
"17.7 Rules for Volatile Variables"
The atomic/non-atomic issue isn't defined in terms of sizes, but
specifically names long and double.
Patricia
Stephen Tenberg
information I am looking for, i.e., whether a java class reference, (i.e., a
"pointer") can be updated atomically.
The rules on 32 vs. 64 bit items (i.e., double and long vs. int) are in a
couple of my java reference books, but I haven't found anything on
references to objects.
Steve
Patricia Shanahan <pa...@acm.org> wrote in message
news:3894730A...@acm.org...
Kevin Riff
atomic, regardless of how many bits the VM uses to store a pointer.
Jim White
<872556$6al$1...@nntp9.atl.mindspring.net>...
>Thanks for the reference. I skimmed the article but didn't really find
the
>information I am looking for, i.e., whether a java class reference,
(i.e., a
>"pointer") can be updated atomically.
If you read 17.1 again you will find that all read/writes are atomic
(except for long and double per 17.4):
:For the purposes of this chapter, the verbs use, assign, load, store,
lock,
:and unlock name actions that a thread can perform. The verbs read,
write,
:lock, and unlock name actions that the main memory subsystem can
perform.
:Each of these actions is atomic (indivisible).
jim
VoToNi
>
>The background thread does some database stuff occasionally, and
>periodically updates the linked list by either appending or removing links.
>
>Meanwhile, the user threads retrieve data from the linked list as users
>request it; always the entire list is scanned.
>
>Originally I wrote everything to use java synchronization so that users
>can't retrieve inconsistent data, but now I am not so sure its needed.
>Since I build a new link first, and then link it last, there is only one
>class reference updated, in other words, the codes says:
>
>last_object.next_link = created_object
>
>So the question, is, are java object references atomic? Is this guaranteed
>to be completed in an interruptible instruction. I have read that java does
>make this guarantee for 32 bit integers, but *not* for 64 bit ones. However
>that article was talking about data.
>
>For that matter, are java references 32 bits on most platforms?
>
There is another problem with caching/registers? java says memory is
synchronized
on "synchronize" and volatiles, this means your reference has no need to be
flushed out of the register,
never given to other threads? theoretically :)
Volker
Joe Seigh
in java always have to be valid references no matter what.
There's nothing to prevent a pathological jvm implementation
from setting the result of an unsynchonized pointer operation
to an undefined valid value. For example, the
reference pointer could be an indirect pointer, a n-bit index
into a table of size 2**n all of whose entries were always
valid values w.r.t pointer operations. Any random value of
0 to 2**n - 1 would be a valid reference.
Fortunately, Sun uses a "wait free" algorithm in the
AWTEventMulticaster which relies on this behavior. Sun
hasn't gotten around to updating the the spec yet, so
far as I know, for this and one other problem with
"wait free" concerning memory visibility. This is
apparently because Sun owns the jvm reference implementation
and nobody who has done a non-reference implementations is
big enough that their complaints about the java class
libraries not being compliant matter very much.
Joe Seigh
Patricia Shanahan
Joe Seigh wrote:
>
> I used to believe this had to be the case because references
> in java always have to be valid references no matter what.
> There's nothing to prevent a pathological jvm implementation
> from setting the result of an unsynchonized pointer operation
> to an undefined valid value. For example, the
> reference pointer could be an indirect pointer, a n-bit index
> into a table of size 2**n all of whose entries were always
> valid values w.r.t pointer operations. Any random value of
> 0 to 2**n - 1 would be a valid reference.
I don't think this is permitted by the JLS. See "17.2 Execution Order"
http://java.sun.com/docs/books/jls/html/17.doc.html#28920 "The actions
performed by the main memory for any one variable are totally ordered;
that is, for any two actions performed by the main memory on the same
variable, one action precedes the other." An action in this sense is a
memory read or write.
Later on, in section 17.4, it is stated that "If a double or long
variable is not declared volatile, then for the purposes of load, store,
read, and write actions they are treated as if they were two variables
of 32 bits each: wherever the rules require one of these actions, two
such actions are performed, one for each 32-bit half. The manner in
which the 64 bits of a double or long variable are encoded into two
32-bit quantities is implementation-dependent."
This is the only exception to atomic treatment of variables that I have
found in the JLS. There is no such exception for references.
This makes sense to me. The rule about long and double is stated to be a
pragmatic concession to current hardware practice - systems that simply
cannot do a 64 bit memory access, and so have to handle long and double
as two separate 32 bit acccesses. "In the future this concession may be
eliminated. Meanwhile, programmers are cautioned always to explicitly
synchronize access to shared double and long variables." It seems
reasonable to assume that a processor that has support for 64 bit
pointers, and address spaces too big to address with 32 bit pointers,
will also have 64 bit atomic memory accesses.
Joe Seigh
>
>
> I don't think this is permitted by the JLS. See "17.2 Execution Order"
> http://java.sun.com/docs/books/jls/html/17.doc.html#28920 "The actions
> performed by the main memory for any one variable are totally ordered;
> that is, for any two actions performed by the main memory on the same
> variable, one action precedes the other." An action in this sense is a
> memory read or write.
>
When a thread uses the value of a variable, the value it
obtains is in fact a value stored into the variable by that
thread or by some other thread. This is true even if
the program does not contain code for proper
synchronization. For example, if two threads store
references to different objects into the same reference value,
the variable will subsequently contain a reference to one
object or the other, not a reference to some other object
or a corrupted reference value. (There is a special
exception for long and double values; see §17.4.)
It is actually saying that reference values are handled like data values
for the purposes of loads and stores. It is also more or less defining
atomicity. Java documentation is a bit squirrelly about saying what object
references really are. They're basically pointers but Java doesn't want to
say that. This has led to a lot of confusion. You see this with a lot of
C programmers, who have experience with pointers in C, when they first start
using Java, having difficulty understanding that putting an object variable
in a method parameter list really means.
It's also why you'll see some leeriness from some people with experience
in concurrent architectures. They've been burned way too many times
by making unwarranted assumptions. Implicit definitions required you
to make assumptions which are prone to error. Explicit definitions are
better. In practice they have a working list of assumptions with
question marks on all the ones they haven't been able to positively
confirm as correct and there tend to be a lot of those.
Anyway, atomicity of pointers doesn't really do you any good. There's
a memory visibility problem. It's pretty much been discussed to death
in comp.threads.programming usually under "double checked locking".
(Yes that book on java programing idioms has it wrong). Unless
you believe that because Sun is doing it in the AWTEventMulticaster that
it is safe for you to make the same assumptions about memory
visibility.
So the only real consequences of object reference atomicity are for
security since you can't corrupt a pointer value and use it to
access system memory.
Joe