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.

The IBM OpenClass IResourceLock class functions like this.

I've been having a discussion on how to avoid the use of mutex semaphores
for simple data structures such as counters and flags. One of the
techniques I have tried to use is writing small assembly language routines
using LOCK along with INC, DEC, BTS, BTR, and other assembler instructions.
 (I got this LOCK prefix idea from a debugging session when I ran across
the IBM C Set++ 2.x fast semaphores code used to protect the heap.) The
intention is that this would be both thread-safe and SMP-safe and would be
cheaper than using mutex semaphores.  However, a question has come up
regarding what would happen if an interrupt occurred between the LOCK and
DEC (or INC, BTS,BTR, etc.) instructions.  As far as I can see, this
shouldn't screw up the code on a single CPU machine because the DEC, INC,
etc. instructions themselves cannot be interrupted because a single CPU
instruction is atomic.  However, I'm not sure what it would do on SMP
hardware.  So far, I haven't been able to find an answer for what would
happen in this situation. Do you know where I might be able to find an
answer to this question?

    LOCK
     (or can it?)
    DEC   [EAX]

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

Or maybe this would be necessary?

    CLI
    LOCK
    DEC [EAX]
    STI

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


--- Maximus/2 2.02