Re: LOCK prefix

From: Robert Wessel (spamtrap_at_crayne.org)
Date: 09/01/04 

Date: Tue, 31 Aug 2004 22:47:08 +0000 (UTC)

" Bern" <spamtrap@crayne.org> wrote in message news:<41343ece$1@news.starhub.net.sg>...
> i got another question:
> what if two processors simultaneously write/read to the same IO port?
>
> is there some synchronisation mechanism?

In short, not much. Architecturally, only aligned I/O accesses have
well defined semantics, although unaligned one (despite being of
rather limited use) do perform more-or-less as expected on all
implementations I'm aware of.

The aligned I/O transactions are basically atomic, however, although
there's no ordering defined between the CPUs. But if you have more
than one processor simultaneously hitting an I/O port without proper
synchronization, you're probably looking at a blue-screen (insert your
favorite operating system's kernel panic display here) in short order.
 Yes, there are a few exceptions to that, but in general access to
device registers cannot be done from more than one thread
simultaneously (whether on a single CPU or many). Consider, for
example, what would happen if you had two processors trying to read
data from a 8250 style serial port. Both might look at 0x3fd
(assuming COM1) and notice that there's a byte available, then try to
read that byte from 0x3f8. One will succeed, the other read garbage.
While that example probably won't lead to a blue-screen, it will lead
to corrupted data. Imagine corrupting data on the disk controller.

The point is that you usually need to make special provisions for
appropriate synchronization in your device driver, usually with some
assistance from the OS. This can be simple or complex, depending on
how much concurrency you want to support for the device and what
facilities the OS offers. For example, in some OSs you can tell the
OS to never reentrantly call your driver, even for interrupts.
Problem solved. For another driver, perhaps for a disk subsystem, you
might want to be able to handle many concurrent requests from
applications, plus multiple devices, plus multiple outstanding
requests per device. In that case, you have to deal with the
synchronization issues at a much more detailed level.

Most I/O devices these days don't implement any I/O ports expect for
compatibility purposes (it's all memory mapped now). But that doesn't
really change anything as far as synchronization of accesses to actual
hardware goes.

Relevant Pages

  • Re: File Object Lock with WDK
    ... COM Port are opened once and used with multiple ... threads using blocking operations (ReadFile, ... It is most probable that one of the users of this driver will use the same ... scenario is that if I am using any out-of-the-box synchronization I am ...
    (microsoft.public.development.device.drivers)
  • Re: File Object Lock with WDK
    ... I only want the driver to be protected from ... I am forwarding the request to the COM port and unless overlapped IO is ... are not related to a Driver's File Object based Lock. ... then use queue level synchronization and each file object is separate ...
    (microsoft.public.development.device.drivers)
  • Re: How should I debug or adobt better data processing for high speed
    ... There is a common myth that volatile variables provide synchronization of some sort. ... About using IO Completion port, I didn't understand how should I use it to ...
    (microsoft.public.vc.mfc)
  • Re: How should I debug or adobt better data processing for high sp
    ... There is a common myth that volatile variables provide synchronization of some sort. ... About using IO Completion port, I didn't understand how should I use it to ...
    (microsoft.public.vc.mfc)
  • Re: File Object Lock with WDK
    ... Serial Port as the lower driver. ... synchronization then I should not use Queue based synchronization and ... Is there any lock object attached to the File Object? ...
    (microsoft.public.development.device.drivers)