STREAMS-UX Programmer's Guide (February 2007)

Differences Between STREAMS/UX and System V Release 4 STREAMS
Differences Between SVR4 MP and HP-UX MP STREAMS
Appendix E
277
Differences Between SVR4 MP and HP-UX MP STREAMS
HP-UX STREAMS provides MP scalability differently from SVR4 MP STREAMS. There are two main
differences.
1. The first pertains to which STREAMS/UX entities run in parallel. SVR4 MP STREAMS executes put and
service procedures for the same queue concurrently although only one instance of a service procedures
can run at a time. HP-UX, unlike SVR4 MP, allows the developer to configure which STREAMS/UX
entities run in parallel. The most parallelism that a STREAMS/UX developer can configure is to run
entry points for different queues concurrently. Unlike SVR4 MP, HP-UX only allows one entry point for a
queue to run at a time. The put and service procedures for the same queue cannot run in parallel. Also,
multiple instances of a queue’s put or service procedure cannot execute concurrently.
2. The second difference has to do with synchronizing access to module and driver private data structures.
SVR4 MP STREAMS does not provide protection for private structures. The module or driver code uses
spinlocks to synchronize access. STREAMS/UX provides protection for private structures. The developer
configures the amount of concurrency for a module or driver based on the entities with which it shares
data structures. For example, if all instances of a module access the same table, the programmer can
configure the module so that only one instance runs at a time.
STREAMS/UX Synchronization Levels
HP-UX STREAMS supports MP scalable drivers and modules. The amount of synchronization for modules
and drivers can be configured. Pick a level which is consistent with a module’s or driver’s use of shared data
structures. STREAMS/UX provides six levels of parallelism which are called queue, queue pair, module,
elsewhere, global, and NOSYNC (described in detail in Appendix F, “Synchronization Levels.”)
The STREAMS/UX synchronization levels also apply to open and close. For example, if a module is configured
for queue pair level synchronization, none of the put or service procedures for the queue pair can run at the
same time as the queue pair’s open or close. Also, open cannot run at the same time as close. The least amount
of protection that STREAMS/UX provides for opens and closes is queue pair. Even if a module is configured
with queue-level synchronization, it will run as if it were configured with queue pair-level synchronization
during opens and closes.
STREAMS does not synchronize the running of timeout and bufcall callback functions with modules and
drivers.
Synchronization levels can be used to protect module and driver private data structures as long as the
driver/module is not configured at SQLVL_NOSYNC.
Strategies for Porting SVR4 MP Modules and Drivers to HP-UX
The best way to port SVR4 MP scalable modules and drivers to HP-UX is to change the SVR4 MP code to use
the STREAMS/UX synchronization levels. First, analyze how the SVR4 MP code shares data structures, and
then configure the modules and drivers to use synchronization levels which correctly serialize access to
shared data. Defines can be used to change module and driver spinlock calls to no-ops. This approach is likely
to get the best performance, but may require much effort. Also, the STREAMS/UX synchronization levels may
not be suitable for all designs.
To make porting easier, STREAMS/UX will provide support for the SVR4 MP spinlock primitives. SVR4 MP
modules and drivers could be ported to HP-UX by configuring them to run with queue synchronization and
leaving in the calls to SVR4 MP spinlock routines. A disadvantage of this porting strategy is that it may not
achieve as much performance as the first. Some of the synchronization provided by STREAMS/UX will be
redundant with the synchronization implemented by module and driver spinlocks. In some cases, a