I found my wascal SMP Pwogwamming wefewence!

MB>  Any given page of code can only run in 
MB> one of the processors at a time, even if it is being called 
MB> from multiple threads. 

  While this is possible, the SMP programming reference doesn't mention this.
If this were true, they should point out that fact since that
reentrant procedures called by multiple threads would not benefit from
SMP.

MB> The main reason for this is that 
MB> device driver code would get extremely confused otherwise, 
MB> since OS/2 internally uses the caller's address to flag its 
MB> blocking and return state.

   Using the caller's address presents the same problem whether
being called from multiple threads or multiple processors.  Device
drivers use the Spinlock resource to protect global
data as required, but don't see the need to prevent
2 processors executing the same page of code.

MB>  A device driver can assert locks against regions of 
MB> memory, and these will be enforced against other 
MB> processors.  

  I couldn't find these memory locks documented in the SMP
reference.  What functions are these?

 MN>   The LOCK instruction is still required for synchronization
 MN> under SMP.  Does this mean that it traps and executes a
 MN> kernel routine to synchronize? 

 MB> I'm not sure I understand your question.  LOCK only 
 MB> gives you one protected instruction at a time.  

The SMP reference says LOCK is required if an application is 
implementing semaphores via INC/BTS etc.  In the 8086 days,
the LOCK was all that was required to be sure that the
instruction it locked the bus for applied to all processors
executing the same instruction.  Now with L1 and L2 cache,
speculative execution, etc, another processor may have
just executed the instruction but results are only in L1 cache.
On a Pentium, does the LOCK also flush L1 and L2 cache of 
all processors before allowing execution?  If not, (guessing out
loud) perhaps it would be necessary to trap, execute an
Inter Processor Interrupt, etc to synchronize the cache(s) before 
executing the instruction.

MB>For practical SMP implementations, 
MB>it must be possible to protect regions of code greater than 
MB>one instruction.  This is handled logically within the 
MB>operating system, not by playing games on the bus.

  Agreed, most applications do not need any special code for SMP,
other than also needing to protect globalVar++ type of operations
with a Mutex and ensuring that thread priorities aren't used for
thread coordination.  Still, the LOCK- stuff is interesting for those
very few applications that require high performance Mutexes.  These
can be at least an order of magnitude faster than DosMutex... calls.

   Mike
--- Maximus/2 2.02