locks on X86

Mon Mar 12 17:43:00 GMT 2001

"Boehm, Hans" wrote:
> I'm assuming that on X86 we'll usually use hash synchronization. I believe
> there will be exactly two time critical instances of cmpxchg in libgcj

But don't we (eventually) want to have the compiler be able to inline the
"lightweight" part of the synchronization mechanism? I was imagining that the
compiler will generate an inline compare-and-exchange which only calls out to
an external function if contention is detected. The external function would do
the spinning and deal with heavyweight (contended) locks.
Of course, the disadvantage here, as Anthony suggests, is that we'd have to
multilib if we wanted faster synchronization on uniprocessors. Obviously if we
don't do any inlining then its much easier because we just generate two
implementation of the lock function, and figure out at runtime which one to
use. Would the benifit of being able to drop the lock prefix outweigh the
benefit of inlining?
regards
 [ bryce ]