MT Configurations

A module or a driver can be either MT SAFE or MT UNSAFE. Beginning with the release of the Solaris 7 system, no MT UNSAFE module or driver will be supported.

MT SAFE modules

For MT SAFE mode, use MT STREAMS perimeters to restrict the concurrency in a module or driver to:

• Per-module single threading

• Per queue-pair single threading

• Per queue single threading

• Per queue or per queue-pair single threading of the put and service procedures with per module single threading of the open and close routines

• Unrestricted concurrency in the put and service procedures with the ability to restrict the concurrency when handling messages that modify data

• Completely unrestricted concurrency

It is easiest to initially implement your module and configure it to be per-module single threaded, and increase the level of concurrency as needed. "Sample Multithreaded Device Driver"provides a complete example of using a per-module perimeter, and "Sample Multithreaded Module with Outer Perimeter" provides a complete example with a higher level of concurrency.

MT SAFE modules can use different MT STREAMS perimeters to restrict the concurrency in the module to a concurrency that is natural given the data structures that the module contains, thereby removing the need for module private locks. A module that requires unrestricted concurrency can be configured to have no perimeters. Such modules have to use explicit locking primitives to protect their data structures. While such modules can exploit the maximum level of concurrency allowed by the underlying hardware platform, they are more complex to develop and support. See "MT SAFE Modules Using Explicit Locks".

Independent of the perimeters, there will be at most one thread allowed within any given queue's service procedure.

MT UNSAFE Modules

MT UNSAFE mode for STREAMS modules were temporarily supported as an aid in porting SVR4 modules. MT UNSAFE are not supported after SVR4..