"Klemme, Robert, myview" wrote:
> what irritates me here is the point that they should not have taken into
> consideration what happens to multithreaded programs. this is because as
> far as i understand support for multithreaded applications is one of the
> core features of the java language.
Multithreading is a lot easier in Java than in any other language I know
of and so is the synchronization between threads using 'synchronize'
blocks. The danger lies in people trying to devise clever schemes to
circumvent the costly locking of objects and not realising their code is
not thread-safe because of that. If you take the conservative approach
and synchronize whenever data is exchanged between threads you're safe.
Anything else must be studied *very* carefully by someone with
sufficient experience in the field.
> ironically the optimization which was implemented for performance
> improvement does lead to a performance loss (because the locking of objects
> is costly) in another place. of course, overall this could still be an
> improvement - especially if most of the code executes "single threaded"...
If this optimization was not allowed, then the JVM would effectively be
forced to synchronize on *every single access* to main memory.
If you take into account that usually most of the useful stuff that a
thread does (i.e.: handling some kind of request/method call/whatever)
does not need synchronization since it stays in its own memory space (I
mean, it uses objects or values that no other thread is modifying), the
performance benefits can be enormous.
Only when communicating other thread, you have to use the synchronized
keyword to insert barriers for these optimizations...
Luc Vanlerberghe
"Klemme, Robert, myview" wrote:
>
> hi!
>
> > -----Original Message-----
> > From: Luc Vanlerberghe [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, January 30, 2001 10:26 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Thread-safety
> >
> >
> > There are IMHO two reasons why these statements may be
> > 'executed' out of
> > order:
> > [...]
>
> tis is all very reasonable.
>
> > 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*
>
> what irritates me here is the point that they should not have taken into
> consideration what happens to multithreaded programs. this is because as
> far as i understand support for multithreaded applications is one of the
> core features of the java language.
>
> > (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.
>
> ironically the optimization which was implemented for performance
> improvement does lead to a performance loss (because the locking of objects
> is costly) in another place. of course, overall this could still be an
> improvement - especially if most of the code executes "single threaded"...
>
> 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]
