Re: locks

["Larry Loen" <lwloen@xxxxxxxxxx>]

>Locks are a function of the task dispatching
>element of the machine and do
>not rely on any processor primitives.  Correct?

Not so.  Any SMP-capable machine needs an "atomic" primative to change a
word of storage that is at the core of doing any kind of locking scheme, be
it mutex or MI locks.

For Intel IA32 it is XCHG.
For 370 the classic was  Compare-and-Swap or Test-and-Set.
PowerPC (AIX) has LWARX and STCWX.

These all manage to alter some bit of storage in a way guaranteed (in some
limited sense) that other processors either didn't also do so in a race
condition (ie two CPUs trying for the same lock) or that if they did, the
fact that more than one CPU was trying can be detected and dealt with.

These can be read up on in appropriate manuals.  In the more modern,
storage-aggressive architectures, these sorts of instructions need to be
accompanied by special "synchronization" primatives as well.  And, while
most of the "atomic" issues arise between CPUs in an SMP, some subset of
the situation may arise even in a Uniprocessor (if the lock primative can
be interrupted by, say, a page fault or time slice end), requring the above
instructions to be used in Unis as well.

What is correct is that these end up being tied, sooner or later, to task
dispatching once the decision to "wait" is made based on some other CPU
winning the race, altering the lock first.


Larry W. Loen  -   Senior Java and iSeries Performance Analyst
                          Dept HP4, Rochester MN


+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---