Craig Swanson wrote in a message to Mike Nice:

 CS> So what about the case where a program has two threads doing
 CS> I/O on two serial ports and the same code is used to do I/O
 CS> on both ports? It sounds like what you two are saying is
 CS> that it is not possible for both threads to be blocked on
 CS> the same DosRead() call in the code at the same time.  If
 CS> this is true, it seems to me this is a serious problem given
 CS> how it is very common for threads doing I/O to spend a lot
 CS> of time being blocked pending I/O completion. 

Application threads are blocked waiting for a device driver.  While a
device driver is reentrant, it is not multithreaded.  The application
threads can be on any processor, but the device driver (or at least its
interrupt service routine) must be running on the master processor.

 CS> I'm under the impression that LOCK does not get trapped, it
 CS> executes directly.  What is confusing me is what happens
 CS> regarding interrupts and LOCK.  For instance:

 CS>     LOCK
 CS>     
 CS>     INC     [ax]

 CS> Does the interrupt get serviced between the LOCK and INC, or
 CS> after the INC?  It seems to me that for LOCK to be truly
 CS> useful,the interrupt should be serviced after the INC.  But
 CS> so far I have not been able to find an answer for this
 CS> question.

It doesn't make any difference whether the interrupt occurs before or after
the INC instruction, as long as the interrupt cannot occur during the
instruction.  In fact, even in single processor systems, a one-pass
instruction such as INC can never be interrupted.  Such use of the LOCK
prefix is therefore basically pointless.  There is a purpose for the LOCK
prefix, but it is completely unrelated to this issue.
 
-- Mike


---