Semantics of Syscalls
Section titled “Semantics of Syscalls”Processes with threads create complications when duplicating or replacing the process image.
fork()
Section titled “fork()”Duplicates the calling process. Problem: what to do with the threads?
2 possible semantics:
- Duplicate only the calling thread
Child gets a single thread. Safe. Predictable. Most used. - Duplicate all threads
Unsafe because child might inherit locks, waiting states, inconsistent memory.
exec()
Section titled “exec()”Replaces the process image. Problem: What happens to the other threads?
In most systesm, all threads except the calling one are destroyed. Any thread-held resources may leak or remain in inconsistent states.
Signal Handling
Section titled “Signal Handling”In UNIX, signal is a construct for notifying processes about events. Signals are handled by either in kernel (by default) or in the process (if overridden by user). When multiple threads are there, the problem is the destination thread of a signal.
Possible destinations:
- Deliver the signal to the thread to which the signal applies
- Deliver the signal to every thread in the process
- Deliver the signal to certain threads in the process
- Assign a specific thread to receive all signals for the process
Synchronous Signals
Section titled “Synchronous Signals”Generated by the thread itself. Must be delivered to the thread that caused it.
Asynchronous Signals
Section titled “Asynchronous Signals”Generated externally. OS must pick one thread to deliver to. Hard to ensure deterministic behavior. Risk of interrupting a thread holding important locks.
Thread Cancellation
Section titled “Thread Cancellation”Target thread is the thread to be cancelled.
Asynchronous Cancellation
Section titled “Asynchronous Cancellation”Kill the thread immediately. Issues:
- Target thread may be holding a lock.
- May be in a critical section.
- Leaves shared data inconsistent.
Deferred Cancellation
Section titled “Deferred Cancellation”Thread checks if it should be cancelled at cancellation points. After that cleanup handler is invoked. Default mechanism.
Issues:
- Harder to implement correctly.
- Programmer must ensure cancellation points exist.
Thread-Local Storage
Section titled “Thread-Local Storage”Aka. TLS. Each thread has its own copy of data.
Issue:
- Need safe mechanism so each thread holds its own copy of a variable.
- Allocation, cleanup, and lifetime of thread-local data must be managed.
- Libraries must avoid accidentally using global variables, which break thread safety.
Scheduler Activations
Section titled “Scheduler Activations”A mechanism to support efficient user-level thread management with kernel awareness. Kernel informs the user-level thread library about events like blocking, preemption, CPU availability using upcalls.
Issues:
- Complexity: Hard for OS + runtime library to coordinate.
- Race conditions between kernel notification and user library response.
- Modern OSes replaced this with 1:1 threading (kernel threads for each user thread).
Used in old OSes. Not used in modern systems.