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.


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) . 


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:

You configure the inner perimeter by choosing one of the mutually exclusive flags shown in Table 12–2.

Table 12–2 Inner Perimeter Flags




The module has an inner perimeter that encloses all the module's queues 


The module has an inner perimeter around each read/write pair of queues 


The module has an inner perimeter around each queue 


The module has no inner perimeter 

Configure the outer perimeter using the flag shown in Table 12–3.

Table 12–3 Outer Perimeter Flag




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




open/close entry points are synchronous.


put/putnext entry points are asynchronous


open/close entry points are asynchronous (experimental)


callbacks (via qtimeout, qbufcall) are asynchronous (experimental)


service procedures are asynchronous (experimental)

Caution – 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.