Choosing a Perimeter Type
Table 12–1 summarizes examples of when to use an inner perimeter, or both an
inner and outer perimeter for a STREAMS module.
Table 12-1 Choosing a Perimeter
Type
| |
|---|
A module where the put procedure reads as well as
modifies module global data. Use a per-module inner perimeter on the single-threaded
module.
| inner
|
A module where all the module private data associated with a queue (or
a read/write pair of queues) can be configured to be single-threaded. Use
an inner perimeter for each corresponding queue (or queue pair) .
| inner
|
A module where most of the module private data is associated with a
queue (or a queue pair); but has some module global data that is mostly read.
Use an inner perimeter for the queue (or queue pair) plus an outer perimeter
for global data. Use qwriter to protect the sections where
it modifies the module's global data (see qwriter). | inner and outer
|
A module that requires higher concurrency for certain message types
while not requiring message ordering. Use an inner perimeter for shared access
to the put procedures. Use an outer perimeter for put procedures that require exclusive access. Use qwriter when
messages are handled in the put procedures that require
exclusive access (see qwriter). | inner and outer
|
A hardware driver can use an appropriate set of inner and outer perimeters
to restrict the concurrency in the open, close, put, and service procedures. With explicit synchronization
primitives (mutex, condition variables, readers/writer,
semaphore), these drivers restrict the concurrency when accessing the hardware
registers in interrupt handlers. When designing such drivers, you need to
be aware of the issues listed in MT
SAFE Modules Using Explicit Locks. | inner and outer
|
|
Several flags specify the inner and outer perimeters (see Table 12–2 and Table 12–3). These flags
fall into three categories:
Define the presence and scope of the inner perimeter
Define the presence of the outer perimeter (which can have
only one scope)
Modify the default concurrency for the different entry points
You configure the
inner perimeter by choosing one of the mutually exclusive flags shown in Table 12–2.
Table 12-2 Inner Perimeter Flags
| |
|---|
D_MTPERMOD
| The module has an inner perimeter that encloses all the module's queues
|
D_MTAPAIR
| The module has an inner perimeter around each read/write pair of queues
|
D_MTPERQ
| The module has an inner perimeter around each queue
|
none
| The module has no inner perimeter
|
|
Configure the outer
perimeter using the flag shown in Table 12–3.
Table 12-3 Outer Perimeter Flag
| |
|---|
D_MTOUTEPERIM
| In addition to an inner perimeter (or none), the module has an outer
perimeter that encloses all the module's queues. This can be combined with
all the inner perimeter options except D_MTPERMOD.
|
|
By default
all synchronous entry points enter the inner perimeter exclusively and enter
the outer perimeter shared. To modify this behavior use the flags shown in Table 12–4.
Table 12-4 Modify Exclusive/Shared
Access Flags
| |
|---|
D_MTOCEXCL
| open/close entry points are synchronous.
|
D_MTPUTSHARED
| put/putnext entry points are asynchronous
|
_D_MTOCSHARED
| open/close entry points are asynchronous
(experimental)
|
_D_MTCBSHARED
| callbacks (via qtimeout, qbufcall) are asynchronous (experimental)
|
_D_MTSVCSHARED
| service procedures are asynchronous (experimental)
|
|
 | Caution - Hardening Information. Concurrency flags
designated with a preceding underbar “_” are experimental, and
their behavior might change in the future and should not be relied upon.
|