This is the mail archive of the
java-discuss@sourceware.cygnus.com
mailing list for the Java project.
Re: Interrupted IO and AWT
Tom Tromey wrote:
> Sometimes I wonder if we should have two locking implementations, one
> as fast as possible and one that is perhaps slower but SMP friendly.
I have wondered this too... it seems like improvement ought to be done
in LinuxThreads, not libgcj, though libgcj is a convenient "proving
grounds" for any sort of experimentation.
Re: SMP, the hardware architectures themselves have limits. I
demonstrated a while ago
(http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00064.html)
that SMP synchronization can be brutally slow due to the CPU cache
ping-pong phenomenon. The easy way to improve your SMP performance is
to downgrade to a uniprocessor... :| Good multithreaded SMP performance
can be very difficult.
Some architectures can be tweaked for single-processor use. The Alpha
CPU uses a load-locked/conditional-store strategy for atomic updates,
followed by a memory barrier to synchronize the cache with main memory.
It is reasonable to leave off the memory barrier on a uniprocessor,
yielding significantly higher throughput.
The x86 architecture relies on atomic swap however, and doesn't seem to
have a similar optimization.
A better question may be: can libgcj benefit from specialized
(architecture-specific) locks? I'm certain it can, as I re-read
Godmar's post on thin locks:
http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00499.html
--
Jeff Sturm
jsturm@sigma6.com