Craig Swanson wrote in a message to Mike Bilow:

 MB> There was an article a few months ago in C++ Users
 MB> Journal which proposed a nice scheme for semaphore
 MB> management in C++ under OS/2.  The idea was to define
 MB> a mutual exclusion class whose constructors and
 MB> detructors would manage the semaphore for you.  This
 MB> allows simply instantiating the proper mutual
 MB> exclusion object as a compiler automatic when your
 MB> routine is entered, and then the compiler handles
 MB> management of it for you.

 CS> The IBM OpenClass IResourceLock class functions like this.

It's probably not an especially unusual idea, but it is worth looking at. 
I'm not at all familiar with IBM OpenClass, and was under the impression
that it was still in development.

 CS> I've been having a discussion on how to avoid the use of
 CS> mutex semaphores for simple data structures such as counters
 CS> and flags. One of the techniques I have tried to use is
 CS> writing small assembly language routines using LOCK along
 CS> with INC, DEC, BTS, BTR, and other assembler instructions. 

This is also a fairly common technique that has been used within Unix for a
very long time.  The concept is that of a "reference counter,"
which is incremented and decremented as things are allocated which refer to
the object. OS/2 actually manages semaphores this way internally.

 CS> (I got this LOCK prefix idea from a debugging session when I
 CS> ran across the IBM C Set++ 2.x fast semaphores code used to
 CS> protect the heap.) The intention is that this would be both
 CS> thread-safe and SMP-safe and would be cheaper than using
 CS> mutex semaphores.  However, a question has come up regarding
 CS> what would happen if an interrupt occurred between the LOCK
 CS> and DEC (or INC, BTS,BTR, etc.) instructions.

LOCK is not actually an instruction, but is an instruction prefix.  When
the LOCK prefix is present, the CPU takes the combination of prefix and
following instruction as a single instruction which is always executed
atomically.  (This is not true of instruction prefixes in general, however,
and especially not true of the REPxx series of prefixes.)

 CS> As far as I
 CS> can see, this shouldn't screw up the code on a single CPU
 CS> machine because the DEC, INC, etc. instructions themselves
 CS> cannot be interrupted because a single CPU instruction is
 CS> atomic.  However, I'm not sure what it would do on SMP
 CS> hardware.  So far, I haven't been able to find an answer for
 CS> what would happen in this situation. Do you know where I
 CS> might be able to find an answer to this question?

An atomic CPU instruction is always guaranteed to be executed atomically
with regard to references into memory.  That is, an SMP system will not
allow one processor to modify a memory location during the execution of a
single instruction in another processor which accesses the same memory
location.  However, the SMP architecture does not provide any protection
against alternating modifications of the same memory location by different
processors, and such things must be managed manually by the programmer if
important.

 CS>     LOCK
 CS>      (or can it?)
 CS>     DEC   [EAX]

 CS> Would the LOCK# signal on the bus still be active when the
 CS> DEC [EAX] runs after the interrupt handler?

No, LOCK gives you exactly one protected instruction.

 CS> Or maybe this would be necessary?

 CS>     CLI
 CS>     LOCK
 CS>     DEC [EAX]
 CS>     STI

 CS> If that's the case, it basically blows my idea out of the
 CS> water for SMP systems because CLI/STI aren't supposed to be
 CS> used in ring 3 code in OS/2 applications. 

OS/2 Ring 3 code is not allowed to manipulate the interrupt enable flag at
all, and there are good and obvious reasons why this is so.  However, OS/2
SMP also restricts interrupt processing to a single CPU, known as the
master CPU, in order to simplify a great many things.  While this has been
argued to be a performance bottleneck, it was probably a good design
choice.

All of this having been said, I still do not understand why the LOCK
instruction prefix buys you anything.  Ordinary DEC/INC instructions are
going to be atomic in all environments, including SMP, and LOCK will not
make successive test-and-modify operations atomic.  As a practical matter,
you need to single-thread the actual management of resources possessing the
reference counters, and you end up having to protect these resources with
system atomic semaphores.  Trying to synthesize semaphores, when they are
provided to you in perfectly safe form by the operating system, seems sort
of foolish to me.
 
-- Mike


---