STREAMS/UX for the HP 9000 Reference Manual

88
STREAMS/UX Multiprocessor Support
Writing MP Scalable Modules and Drivers
and service routines cannot block. This means, for example, that modules and
drivers which run over a UP emulation hardware driver must run under UP
emulation.
• Modules and drivers which can run both MP scalable and under UP emulation
must use queue or queue pair synchronization. An example of an MP scalable
module which can run in UP emulation mode is timod. Although timod is
configured to be MP scalable, it is pushed onto many streams, some of which run
in UP emulation mode.
• The MP scheduler runs differently from the uniprocessor scheduler. This may
affect STREAMS/UX application programs. On multiprocessor systems, the
scheduler may not run a service routine before the process which scheduled the
routine returns to user level.
• A module or driver's synchronization level determines the entities with which it
can share data. It also determines the entities with which it can share its
STREAMS/UX queues. For example, if a module uses queue pair
synchronization, the write put routine can call insq to insert a message onto the
module's read queue. But, if the module uses queue synchronization, the write
put routine can only call insq to insert messages onto the write queue. The
synchronization level determines which queues a module or driver can pass to
STREAMS/UX utilities.
In general, a put or service routine can only pass its own queue or queues
belonging to entities with which it can share data. The restricted utilities are
backq, bcanputnext, canputnext, flushband, flushq, 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 a driver's read queue or a lower mux's
write queue. However, putq's caller must guarantee that the queue passed in 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 different
way from those listed above. A put or service routine can only pass its own
queue's q_next field or the q_next field of queues belonging to entities with
which it can share data. These requirements apply to bcanput, canput, put,
putctl, putctl1, putctl2, and streams_put. These utilities are not restricted when
they are passed a parameter of the form q, except that the queue must still be
allocated.
• Some restrictions exist for timeout and bufcall callback routines as well as
non-STREAMS/UX code in the kernel. This software cannot share data