There are IMHO two reasons why these statements may be 'executed' out of
order:
1. If the compiler (or the JVM executing the bytecode) can prove that
the reordering won't have any effect *on the current thread* (in this
case, the value is not referenced elsewhere *in the current thread*,
then reordering is allowed (with some restrictions like those concerning
the synchronized blocks). This makes sure that all assignments made by a
thread will be seen in that order by *that* thread. If there are no
restrictions within a certain amount of code, then the compiler/JVM is
free to reorder those instructions to improve performance.
2. Even if the instructions are executed in order, the memory subsystem
can flush the writes to main memory in another order than the process
wrote them to the memory subsystem (again with certain restrictions). I
think this case is even easier to visualise than the preceding one. If,
in a multiprocessor system every write to a variable has to be
accompanied by extensive communication between caches on all levels to
make sure everything happens in order, there would be a serious
performance hit. I'm not familiar with the architecture of current
multiprocessor systems, but I'm pretty sure that the restrictions on the
order of memory stores has been relaxed as well for the general case,
but that they all have some way to garantee consistency when the need
arises. Since the Java bytecode runs on an abstract machine, the
designers of the language needed a system to have an abstract way of
specifying this 'consistency' and they included it in the synchronized
statement.
To summarize:
The designers of the JVM spec relaxed the requirements on order of
execution to allow as much performance as possible while still
guaranteeing the outcome of a program *if it is run in a single thread*
(I believe the word is 'deterministic').
Whenever there's communication between threads, the programmer must be
*very* careful to ensure that the state seen by one thread corresponds
to the one written by another.
AFAIK the only mechanism the Java language provides to ensure this is
the use of synchronized blocks.
Luc Vanlerberghe
"Klemme, Robert, myview" wrote:
>
> thank you paul to point me at an omission.
>
> > -----Original Message-----
> > From: Paul Speed [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, January 29, 2001 11:54 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Thread-safety
> > [...]
> > The problem is that the point of the code block is to be
> > sure that the _jspx_init() method has been completed before
> > proceeding. The problem is that _jspx_inited might appear to other
> > threads to be set to true before the original thread has completed
> > executing the _jspx_init() method (or at least before its changes
> > are available to other threads).
> >
> > This means that the second thread would come through, see
> > that _jspx_inited is true, and skip the synchronization block. That
> > threads execution would then proceed thinking that everything has
> > been initialized when it hasn't.
>
> ok, i see. thank you again for clarifying. do i now fully understand the
> issue: the problem at hand cannot easily be solved by assigning the flag
> from the return value of the init() method because of a combination of
> inlining and reordering which might again lead to a prior assignment. is
> that so?
>
> normally i would say that a code like "_jspx_inited = do_init();" may not be
> rearranged in a way that the assignment occurs prior to finishing of the
> method body (especially since there can be exceptions). i would guess that
> - by allowing this - a whole bunch of programs would run berserk or simply
> break... i cannot believe that people at sun would risk these consequences,
> do they?
>
> > Check out the article that is referenced in other mail in
> > this thread or hit JavaWorld and see the references section on the
> > article about singletons.
>
> this one?
> http://www.javaworld.com/javaworld/jw-04-1999/jw-04-toolbox.html
>
> regards
>
> robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
