Managing threads concurrency

The size of the pool of available LWPs (the ``actual concurrency level'') will vary over time. The Threads Library manages the size of this pool automatically and dynamically according to rules outlined below. The programmer can influence the algorithm by changing the ``requested concurrency level'' (with thr_setconcurrency, see below); at times, the actual concurrency level may be either greater than or less than the requested level.

The rules governing implicit changes to the actual concurrency level are:

• Initially, for each program, there is a single LWP available for execution of threads.

• The size of the pool is incremented when a thread is created with the THR_INCR_CONC flag to thr_create(3thread).

  ---

  NOTE: The newly created thread is not necessarily picked up by that newly created LWP.

  ---

• If all of the LWPs of a process are blocked in system calls, then the process cannot execute any threads. However, the kernel sends a SIGWAITING type signal to the process when this condition occurs. Additional LWPs are created if there are additional runnable threads.

• The number of LWPs should not exceed the number of threads -- at least not for long -- that would be wasteful. An LWP that remains unassigned to a thread for a certain time (5 minutes) is said to have ``aged'' and will be terminated [_lwp_exit(2)]. Aging will terminate LWPs until the size of the pool equals the lesser of

  • requested level of concurrency

  • number of active (running or runnable) threads
  Thus, if there are few threads, the actual number of LWPs may be less than the requested level.

A thread can use the thr_setconcurrency(3thread) function to change the requested concurrency level mentioned in the algorithm above. The syntax is:

   int thr_setconcurrency(
   	int new_level
   );

This request is serviced asynchronously.

The rules governing the explicit changes in actual concurrency by thr_setconcurrency(3thread) are:

• When the level is increased, the number of LWPs is increased.

  One implication is that certain errors (for example, EAGAIN -- system limit on LWPs per user exceeded) may not be reported because they occur after thr_setconcurrency returns.

• A request to lower the level of concurrency does not have an immediate effect: no LWP is terminated, nor is any thread preempted. Instead, the actual level of concurrency becomes lower by the LWP aging described above.

• Setting new_level to 0 requests the default level of concurrency.

• The programmer can retrieve the current value of the requested level of concurrency with the thr_getconcurrency(3thread) function.

• There is no mechanism to return the current, actual level of concurrency.