Interrupted IO and AWT

Tue Mar 21 08:06:00 GMT 2000

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