CS> It is possible that OS/2 applications will sometimes execute
 CS> on SMP (symmetric multiprocessing) systems.  In this case,
 CS> it is entirely possible that "same time" will be literally
 CS> true as one thread can be running on each CPU, meaning
 CS> multiple threads are literally running simultaneously.

 MB> OS/2 SMP never actually does this.  Any given page of code can only run
 MB> in one of the processors at a time, even if it is
 MB> being called from multiple threads. The main reason
 MB> for this is that device driver code would get
 MB> extremely confused otherwise, since OS/2 internally
 MB> uses the caller's address to flag its blocking and
 MB> return state.

Hmm, that seems like a kludge to me.  How does it enforce this limitation? 
Does it do something along the lines of when the scheduler decides to give
a CPU to another thread, it marks the page on which the formerly running
thread was interruped so that if any other thread tries to touch that page
it will cause an exception that the scheduler will intercept?

Taking this a step further, this seems to imply that two threads could not
be I/O blocked at the same instruction.  For instance, if two threads were
running through the same serial port read code, they could not be both
blocked on the DosRead() call used to get data out of the serial port each
one is handling.  This doesn't sound right to me, but I don't know OS/2
internals all that well.

Do other SMP-capable operating systems suffer from this limitation? It
would seem rather odd to me if a system was designed for SMP from the
ground up.

 CS> Making code SMP-safe takes it one step further as you must
 CS> then consider that some practices that would be safe on a
 CS> single CPU system will not be safe on a multiple CPU system.
 CS>  For instance, a simple Intel x86 INC instruction used to
 CS> update a counter being handled by multiple threads would
 CS> need to have a LOCK prefix before it to make it SMP-safe.

 MB> The LOCK instruction has nothing to do with the other
 MB> processor in SMP, but simply reserves the bus.  It
 MB> dates back to the 8086, which certainly had no SMP
 MB> support!  Rather, locks in SMP are exchanged logically
 MB> within the operating system.

I know the LOCK prefix dates back to the 8086 and 8088 for use with the
8087 math coprocessor, but Borland's TASM documentation refers to it being
used with multiprocessors:

    The LOCK prefix causes the LOCK# signal of the CPU to be asserted
    during execution of the instruction that follows it.  In a
    multiprocessor environment, this signal can be used to ensure that
    the CPU has exclusive use of any shared memory while LOCK# is
    asserted.  The read-modify-write sequence typically used to
    implement test-and-set on the 386 is the BTS instruction.

    On the 386 and i486, the LOCK prefix functions only with the
    following instructions:

    BT, BTS, BTR, BTC   mem, reg/imm
    XCHG                reg, mem
    XCHG                mem, reg
    ADD, OR, ADC, SBB   mem, reg/imm
    AND, SUB, XOR
    NOT, NEG, INC, DEC  mem

    An undefined opcode trap will be generated if a LOCK prefix i used
    with any instruction not listed above.

    XCHG always asserts LOCK# regardless of the presence or absence of
    the LOCK prefix.

    The integrity of the LOCK is not affected by the alignment of the
    memory field.  Memory locking is observed for arbitrarily
    misaligned fields.

    Lock access is not assured if another CPU processor is executing
    an instruction concurrently that has one of the following
    characteristics:

        * Is not preceded by a LOCK prefix.

        * Is not one of the instructions in the preceding list.

        * Specifies a memory operand that does not exactly overlap the
          destination operand.  Locking is not guaranteed for partial
          overlap, even if one memory operand is wholly contained
          within another.


Moreover, IBM used LOCK prefixes in the C Set++ 2.x fast semaphores used to
protect the heap.  If LOCK does nothing, then why did they use it?


--- Maximus/2 2.02