Phil Crown wrote in a message to Craig Swanson:

 CS> Making code thread-safe usually involves the following:

 CS> 1) Avoid global variables

 CS> 2) Use local (i.e., auto or allocated on the stack) variables

 PC> Does this mean making sure that the compiler/optimizer
 PC> doesn't register any local variables?  Someone mentioned a
 PC> bug in Borland that it was ignoring the command not to
 PC> register local variables or something like that. 

No, no... register variables are as thread-safe as stack variables.  What
is unsafe are variables allocated in memory if the address is known by more
than one thread, a condition true of all global variables of any storage
class and of local variables of static storage class.  In order to access
memory in a way that is thread-safe, you need to keep its address locally
on the stack or in a register so that other threads do not see it.

When OS/2 switches threads, it takes responsibility for preserving the
stack and registers across the switch.  Each thread task owns its private
set of state information, including stack and register values, so thread
switching is transparent to all threads.

I have no idea what you mean about the supposed Borland bug, by the way.  I
can't imagine how any compiler could function without being allowed to use
the registers.

 CS> 3) Protect resources that are not strictly local using mutex
 CS> semaphores or handle them using some other scheme such as atomic
 CS> bit test-and-set, inc/dec, and exchange operations

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

 PC> I know how to use mutex semaphores and I doubt anything I
 PC> write will ever run on an SMP system.

In theory, any code properly written to enforce serialization on a single
processor system will work unmodified on a multiprocessor system.  However,
it is not uncommon for code to be written that fails to explicitly enforce
a required serialization, but which never actually fails on a single
processor system.  Such a "harmless" bug will cause trouble on a
multiprocessor system.
 
-- Mike


---