Skip Navigation Links | |
Exit Print View | |
STREAMS Programming Guide Oracle Solaris 11.1 Information Library |
Part I Application Programming Interface
2. STREAMS Application-Level Components
3. STREAMS Application-Level Mechanisms
4. Application Access to the STREAMS Driver and Module Interfaces
7. STREAMS Framework - Kernel Level
8. STREAMS Kernel-Level Mechanisms
11. Configuring STREAMS Drivers and Modules
Routines Used Inside a Perimeter
Asynchronous Callback Functions
Unloading a Module that Uses esballoc
MT SAFE Modules Using Explicit Locks
Sample Multithreaded Device Driver Using a Per Module Inner Perimeter
Sample Multithreaded Module With Outer Perimeter
14. Debugging STREAMS-based Applications
B. Kernel Utility Interface Summary
The SunOS 5 operating system is fully multithreaded, which means that it can make effective use of the available parallelism of a symmetric shared-memory multiprocessor computer. All kernel subsystems are multithreaded: scheduler, virtual memory, file systems, block/character/STREAMS I/O, networking protocols, and device drivers.
MT STREAMS requires you to use some different concepts and terminology. These concepts apply not only to STREAMS drivers, but to all device drivers in the Oracle Solaris operating environment. For a more complete description of these terms, see Writing Device Drivers. Additionally, see Chapter 1, Overview of STREAMS of this guide for definitions and Chapter 8, STREAMS Kernel-Level Mechanisms for elements of MT drivers.
Some of the multithreaded terms and ideas are.
Sequence of instructions executed within context of a process.
Mechanism to restrict access to data structures.
Restricting access to a single thread.
Allowing two or more threads access to a data element.
Two or more CPUs concurrently executing the Operating System.
Simultaneous execution.
Suspending execution for the next thread to run.
Portion of code that is single-threaded.
Exclusive access to a data element by a single thread at one time.
Kernel event synchronization primitives.
Memory-based synchronization mechanism.
Data lock allowing one writer or many readers at one time.
On occurrence of a specific event, call a module function.
Only one thread is allowed in the perimeter. Upon return from a call the action is complete; when the thread is done, the job is done.
Multiple threads are allowed in the perimeter. Upon return form a call there is no guarantee that the job is complete.
A thread has synchronous access in the perimeter. The claim prevents subsequent synchronous access until the claim is released.
Calling a synchronous entry point in the perimeter.
A thread that has exclusive access to a perimeter.