Synchronization and Thread Management

Multi-CPU Systems and Thread Synchronization

Concepts of Threading and Synchronization

  • User Level Threads vs. Kernel Level Threads

    • User Level Threads: Managed by the user-level thread library.

    • Kernel Level Threads: Managed by the operating system through kernel.

Scenario Description

  • Situation Overview

    • User Level Thread T1 is executing on CPU 1 and is currently holding a mutex.

    • Concurrently, another thread, T4, requires the same mutex but is scheduled on CPU 2.

Mutex Behavior in Multi-CPU Systems

  • When T4 attempts to acquire the mutex held by T1:

    • Default Behavior: Normally, T4 would be queued for the mutex.

    • This results in potential performance inefficiencies in multi-CPU environments.

Adaptive Mutexes

  • Definition: Adaptive mutexes are designed to optimize behavior based on the expected duration of critical sections.

  • Performance Strategy:

    • Short Critical Sections:

    • If T1’s critical section is short, it is more efficient for T4 to spin (actively wait) rather than be blocked and context-switched to the mutex queue.

    • This allows T4 to resume execution without the overhead of context switching if T1 releases the mutex soon.

    • Long Critical Sections:

    • For longer critical sections, T4 will be queued and blocked until the mutex is released.

  • Rationale:

    • Using adaptive mutexes makes sense in multi-CPU systems where the owner of the mutex could be executing on another CPU. In single CPU systems, spinning is generally not beneficial.

Importance of Mutex Ownership Information

  • Mutex Ownership: Maintaining information about the mutex owner can aid in decision-making when a thread requests a mutex.

  • Check on Owner:

    • If the mutex is busy, by identifying the owner:

    • If it’s on a different CPU, determine whether to spin or block.

    • Consideration of expected execution times for the critical section informs whether the block or spin strategy should be employed.

Thread Management and Destruction

  • Thread Lifecycle: After a thread exits, it should be destroyed to free its resources.

  • Performance Consideration:

    • Thread creation is resource-intensive (requires allocation and initialization of data structures).

    • Reusing resources can enhance performance.

  • Death Row Concept:

    • Exiting threads enter a ‘death row’ state instead of being immediately destroyed.

    • A special Reaper thread periodically performs garbage collection, cleaning up data structures associated with those threads marked for destruction.

    • If a new thread request comes in before the previous thread is fully destroyed, the existing structures can be reused, optimizing resource allocation.

  • Performance Gains:

    • This mechanism reduces overhead of repeated allocations and accelerates thread initiation.