Hardware Reference
In-Depth Information
one process control (or even create) threads in a different process. This feature is
useful for debuggers, for example.
Processes can communicate in a wide variety of ways, including pipes, named
pipes, sockets, remote procedure calls, and shared files. Pipes have two modes:
byte and message, selected at creation time. Byte-mode pipes work the same way
as in
UNIX
. Message-mode pipes are somewhat similar but preserve message
boundaries, so that four writes of 128 bytes will be read as four 128-byte mes-
sages, and not as one 512-byte message, as would happen with byte-mode pipes.
Named pipes also exist and have the same two modes as regular pipes. Named
pipes can also be used over a network; regular pipes cannot.
Sockets are like pipes, except that they normally connect processes on different
machines. However, they can also be used to connect processes on the same ma-
chine. In general, there is usually little advantage to using a socket connection
over a pipe or named pipe for intramachine communication.
Remote procedure calls are a way for process
A
to have process
B
call a proce-
dure in
B
's address space on
A
's behalf and return the result to
A
. Various restric-
tions on the parameters exist. For example, it makes no sense to pass a pointer to a
different process. Instead, the object(s) pointed to have to be bundled up and sent
to the destination process.
Finally, processes can share memory by mapping onto the same file at the
same time. All writes done by one process then appear in the address spaces of the
other processes. Using this mechanism, the shared buffer used in our pro-
ducer-consumer example can be easily implemented.
Just as Windows 7 provides numerous interprocess communication mechan-
isms, it also provides numerous synchronization mechanisms, including sema-
phores, mutexes, critical sections, and events. All of these mechanisms work on
threads, not processes, so that when a thread blocks on a semaphore, other threads
in that process (if any) are not affected and can continue to run.
A semaphore is created using the
CreateSemaphore
API function, which can
initialize it to a given value and define a maximum value as well. Semaphores are
kernel objects and thus have security descriptors and handles. The handle for a
semaphore can be duplicated using
DuplicateHandle
and passed to another process
so that multiple processes can synchronize on the same semaphore. Semaphores
can also be given names when they are created so that other processes can open
them by name. Calls for
up
and
down
are present, although they have the speculiar
names of
ReleaseSemaphore
(
up
) and
WaitForSingleObject
(
down
). It is also pos-
sible to give
WaitForSingleObject
a timeout, so the calling thread can be released
eventually, even if the semaphore remains at 0 (although timers reintroduce races).
Mutexes are also kernel objects used for synchronization, but simpler than
semaphores because they do not have counters. They are essentially locks, with
API functions for locking (
WaitForSingleObject
) and unlocking (
ReleaseMutex
).
Like semaphore handles, mutex handles can be duplicated and passed between
processes so that threads in different processes can access the same mutex.
