Re:
> In our porting effort we need an atomic instruction for obtaining a latch
> and having other processes in spinlock...   On HP-UX we use the ldcw
> assembly instruction for obtaining a latch.  The problem seems to be that


UGLY!

IMHO, users should *NEVER* use spinlocks of any kind, for a variety of
reasons:

  1) they're *very* easy to code wrong...so that they work 90 to 99.999999%
     of the time.

  2) they're *very* easy to misuse, and eat a lot of CPU that other
     users should be using.

  3) do processes waiting on the lock boost the priority of the person
     holding the lock, if the waiter is more important?  They should!

  4) does the spinlock code give up after a while (say, 100 spins), and
     use a blocking wait of some kind?  (Be kind to the other users)

I *STRONGLY* recommend using a vendor-provided locking mechanism.  If there
isn't a high-speed / low-cost locking facility on a particular operating
system, then *make the vendor give you one*.  That's their responsibility.

I ranted and ranted about this to the HP Solutions Provider Program, because
they encouraged people to roll their own on HP-UX, and provided sample code.

What happened?  You *better* have guessed it: a few months later, HP sent out
an alert, telling users that there was a bug in the spinlock code that they'd
suggested using.

If HP had simply exposed a high-speed / low-cost lock (perhaps via the low
overhead system call mechanism that's already in HP-UX), then if they'd
made an error, they could release a patch and *EVERYONE'S* program would
be corrected.  Now, a user doesn't know: which third-party vendors have written
it correctly, which haven't.



I EXTREMELY STRONGLY recommend against a roll-your-own spinlock.



Ok...what about MPE?

MPE has a very robust set of locking mechanisms you can choose from.

Here's the cost of various mechanisms (for when the lock is "available"):

             Average #
Test Name :      Ticks  (that's low-level clock ticks, BTW)
----------: ----------
empty     :       24.1
ldcws     :       39.5    <-- just cost of LDCWS, not the rest of the code!
cblock    :      446.1
SIR       :     1201.9
FLOCK fIN :     3455.8
FLOCK fIO :     3683.7
FLOCK mIN :     3440.3
FLOCK mIO :    18257.4    <--- drastically better if file being locked is EMPTY
gloRIN    :    42830.7
locRIN    :    47758.6


Note that the times are in clock ticks ... the cblock took 446 ticks, which
is about 4 *MICRO*seconds (on an HP 3000/968, which is a 64 MHz machine).

I strongly suspect that nothing most people do is worth worrying about 4
microseconds per cblock call!


BTW, this is 30 *YEARS* of multi-processor experience talking here...
*please* listen!


Stan Sieler                                           [log in to unmask]
www.allegro.com/sieler/wanted/index.html          www.allegro.com/sieler