AIX Version 4.3 Differences Guide

The user scheduler maintains a runqueue of runnable local pthreads and
dispatches them on available kernel threads. Each kernel thread is represented
in the pthreads library by a virtual processor structure (VP). There is a 1:1
mapping between VPs and kernel threads.
The user scheduler catches a SIGWAITING signal. Applications should not catch
this signal, it is only for system use.
Each time a local pthread is created, terminates, or goes to sleep in the library,
the user scheduler examines the ratio of kernel threads to active and sleeping
user pthreads. If they are not consistent with the required values, then VPs, and
hence, kernel threads, are created or destroyed as required. A VP that is to be
deleted first places the user pthread it was running on to the queue of runnable
pthreads maintained by the library. It then adds itself to the list of zombie VPs,
and marks the underlying kernel thread for termination. The user scheduler
traverses the list of zombie VPs on a regular basis and deletes the redundant VP
structures.
Time slicing of local threads is initiated by the AIX scheduler, which sets a flag in
the currently running kernel thread once it has obtained a full timeslice. On return
from the clock tick interrupt handler, if the timeslice flag is set, the thread will call
the user scheduler. The user scheduler places the current local thread on the
local pthreads library runqueue and then selects the highest priority thread to run.
If there are no threads on the run queue, then the current thread continues to run.
The user scheduler controls which pthreads are woken when a pthread event
occurs. For example, when a mutex lock is released. The sleeping pthreads may
have system-wide (global) or process-wide (local) contention scope. The user
scheduler favors pthreads with system-wide scope over those with process-wide
scope, regardless of their priorities. Priority is only used to decide between
pthreads with the same contention scope. If they have the same priority, then the
pthread that has been waiting the longest will be woken first.
When a local pthread makes a system call, it may block in the kernel waiting for a
response from the system call. In this instance, the kernel thread and VP are not
available to run another local pthread.
Consider a process with N+1 local threads, and N VPs, where one thread writes
data to a pipe, and N threads read data from the pipe. The process would
encounter a deadlock situation when the N threads reading from the pipe were
blocked in the kernel. There would be no VP available for the N+1 thread to run
on to write data to the pipe. This situation is avoided by a special check in the
routine that a thread calls when about to block in the kernel. If the thread about to
block is on the only VP of the process that is not already blocked, then the user
scheduler is activated and instructed to create a new VP and kernel thread to run
another local thread.
4.3.4 Mutex Locks
In previous versions of AIX, when a mutex lock is blocked, a pthread attempting
to get the lock sleeps in the kernel. The internal structure of the mutex lock has
been changed so that the list of threads waiting for the mutex is maintained in the
user address space by the pthreads library. This is to allow the user scheduler to
achieve relatively uniform levels of multiplexing over the remaining pthreads
Application Development and Pthreads 73