Re: Fast locking (Was Re: Java vs Ada 95)

[kilgallen@eisner.decus.org (Larry Kilgallen)]

In article <55r16k$m00@fozzie.sun3.iaf.nl>, geert@fozzie.sun3.iaf.nl (Geert Bosch) writes:

> I can't imagine there are many systems around these days that do not
> provide efficient test-and-set semantics. Even the 8088 processor that
> does not directly have a test-and-set instruction can easily emulate
> one by doing an atomic swap between a processor register and a memory
> location. On very simple processors it is almost always possible to
> block all interrupts while doing the test-and-set.

"Blocking all interrupts" in a multiprocessor environment would be
hazardous to the speed of other, non-interfering, activities.

> Of course machines that do not have any instructions that can be used
> to efficiently implement hardware-assisted locking will not have a
> test-and-set intrinsic sub-program, but of course nobody expects to
> magically be able to use hardware locking support when the target
> platform does not have it. The point is that *when* it is available,
> it should be usable in a consistent way.

My complaint is not that some machines lack fast locking primitives,
but rather that there was an assumption that those primitives will
always be "test and set".  DEC designers made the choice that their
"load-locked/store-conditional" semantics would be faster than more
traditional approaches.  Since they consistently win the SpecFP
and SpecInt comparisons with each new chip, I presume they know
what they are doing about fast hardware (although the portion of
their design having to do with locking primitives has nothing to
do with the portion of their design needed for the rather limited
SpecFP and SpecInt tests).

Larry Kilgallen