When modifying a STREAMS driver to take advantage of the multithreaded kernel, a level of MT safety is selected according to:
The desired degree of concurrency
The natural concurrency of the underlying module
The amount of effort or complexity required
Much of the effort in conversion is simply determining the appropriate degree of data sharing and the corresponding granularity of locking (see Table 12–1). The actual time spent configuring perimeters and/or installing locks should be much smaller than the time spent in analysis.
To port your module, you must understand the data structures used within your module, as well as the accesses to those data structures. You must fully understand the relationship between all portions of the module and private data within that module, and to use the MT STREAMS perimeters (or the synchronization primitives available) to maintain the integrity of these private data structures.
You must explicitly restrict access to private module data structures as appropriate to ensure the integrity of these data structures. You must use the MT STREAMS perimeters to restrict the concurrency in the module so that the parts of the module that modify private data are single-threaded with respect to the parts of the module that read the same data. (For more information about perimeters, see MT STREAMS Perimeters.) Besides perimeters, you can use the synchronization primitives available (mutex, condition variables, readers/writer, semaphore) to explicitly restrict access to module private data appropriate for the operations within the module on that data.
The first step in multithreading a module or driver is to analyze the module, breaking the entire module up into a list of individual operations and the private data structures referenced in each operation. Part of this first step is deciding upon a level of concurrency for the module. Ask yourself which of these operations can be multithreaded and which must be single-threaded. Try to find a level of concurrency that is “natural” for the module and matches one of the available perimeters (or, alternatively, requires the minimal number of locks) , and has a simple and straightforward implementation. Avoid additional unnecessary complexity.
Typical questions to ask are:
What data structures are maintained within the module?
What types of accesses are made to each field of these data structures?
When is each data structure accessed destructively (written) and when is it accessed non-destructively (read)?
Which operations within the module should be allowed to execute concurrently?
Is per module single-threading appropriate for the module?
Is per queue-pair or per queue single-threading appropriate?
What are the message ordering requirements?