STREAMS/UX for the HP 9000 Reference Manual

Differences Between STREAMS/UX and System V Release 4 STREAMS

STREAMS/UX Uniprocessor Synchronization

This section describes STREAMS/UX synchronization on a uniprocessor

system. Chapter 4 discusses multiprocessor synchronization. Also, Chapter

4 describes how modules and drivers running on a uniprocessor system can

use multiprocessor synchronization mechanisms to protect against

interrupts. STREAMS/UX programmers must follow the guidelines listed

below as well as those in the SVR4.2 STREAMS manual.

STREAMS/UX provides the following types of synchronization on a

uniprocessor system:

• STREAMS/UX protects its internal data structures from interrupts.

• STREAMS/UX helps protect module and driver private data structures against

interrupts.

• STREAMS/UX allows multiple processes to perform operations on the same

stream.

• The STREAMS/UX scheduler synchronizes the running of service routines with

application processing.

STREAMS/UX Internal Synchronization

STREAMS/UX protects its internal data structures, such as message queues,

against interrupts. STREAMS/UX programmers must use the following

guidelines.

1 A put, service, open, or close routine can pass its own queue or the other queue

in its queue pair to a STREAMS/UX kernel utility. Many STREAMS/UX utilities

operate on a queue. For example, getq takes a queue as an input parameter and

returns a message from the queue. A service routine can only pass its queue or

the other queue in its queue pair to getq. The restricted utilities are backq,

bcanputnext, canputnext, ﬂushband, ﬂushq, freezestr, getq, insq, putbq, putnext,

putnextctl, putnextctl1, putnextctl2, putq, qreply, qsize, rmvq, SAMESTR, strqget,

strqset, and unfreezestr. The putq utility is not restricted when it is passed a

driver's read queue or a lower mux's write queue. Any put or service routine can

call putq if it passes it a driver's read queue or a lower mux's write queue.

However, putq's caller must guarantee that the queue passed is still allocated.

Some STREAMS/UX utilities, such as canput, are commonly passed a parameter

of the form q->q_next. These routines are restricted in a slightly different way