STREAMS Programming Guide

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


Module Description	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


Flag	Description
`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


Flag	Description
`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


Flag	Description
`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`	`callback`s (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.