JAVA-BASED REAL-TIME PROGRAMMING

3. Multi-Threaded Programming
break the rules. Before doing that, be aware of the previos section and the
following:
1. As a way of doing manual performance optimization, small get and set
methods (belonging to a monitor with other methods synchronized) are
often not declared synchronized. However, the way it is done is (as
far as the author has seen) mostly wrong, resulting in very-hard-to-find
bugs when the program is run on some platforms. Therefore, keep the
following in mind:
• Only access data that is consistent all the time. Even if getting
an integer can be done atomically, that attribute may have an inconsistent
value due to computations in the synchronized methods.
In a non-final class with non-private attributes, you cannot know
what subclasses will do.
• Only access a single single-word value (built in type or object reference)
by a non-synchronized monitor method, and if not declared
volatile, make sure that the updated value is obtained (by other
system calls resulting in memory being updated, or by only permitting
a single-threaded write during startup or similar). Even if
you figure out that several attributes can be changed due do the
logic of other methods, the risk is too high that errors are introduced,
for instance when the class is extended or enhanced. An
acceptable single-word access could be an object reference that is
final (set in constructor) but needs to be frequently obtained by
other threads.
• Attributes (except those of types double or long that need synchronization
to be portable in any case) accessed without synchronization
should be declared volatile. According to the Java language
specification, all types except long and double are atomically accessed.
For object references it is of course crucial that the address
value does not get corrupted, which would break the built-in safety
(the so called sandbox model) of Java. The only data-type you can
assume being atomically accessed in native code on all platforms
is the byte, so implementation of native methods (and virtual machines
and Java native compilers) requires some care, in particular
for CPUs with word length less than 32 bits.
• Comment your assumptions and decisions when you are doing this
type of (what you think is) clever programming.
Hence, be careful when skipping synchronization; such optimization is
better done by compilers and class loaders.
2. When developing software libraries or components that should stand
also improper usage, such as a synchronized block locking a monitor
72 2012-08-29 16:05