Contention scope and concurrency level

The contention scope of a user thread defines how it is mapped to a kernel thread

. The threads library defines the following contention scopes:

PTHREAD_SCOPE_PROCESS: Process contention scope, sometimes called local contention scope. Specifies that the thread will be scheduled against all other local contention scope threads in the process. A process-contention-scope user thread is a user thread that shares a kernel thread with other process-contention-scope user threads in the process. All user threads in an M:1 thread model have process contention scope.
PTHREAD_SCOPE_SYSTEM: System contention scope, sometimes called global contention scope. Specifies that the thread will be scheduled against all other threads in the system and is directly mapped to one kernel thread. All user threads in a 1:1 thread model have system contention scope.

In an M:N thread model, user threads can have either system or process contention scope. Therefore, an M:N thread model is often referred as a mixed-scope model.

The concurrency level is a property of M:N threads libraries. It defines the number of virtual processors used to run the process-contention scope user threads. This number cannot exceed the number of process-contention-scope user threads and is usually dynamically set by the threads library. The system also sets a limit to the number of available kernel threads.

Setting the contention scope

The contention scope can only be set before a thread is created by setting the contention-scope attribute of a thread attributes object. The pthread_attr_setscope subroutine sets the value of the attribute; the pthread_attr_getscope returns it.

The contention scope is only meaningful in a mixed-scope M:N library implementation. A TestImplementation routine could be written as follows:

int TestImplementation()
{
        pthread_attr_t a;
        int result;

        pthread_attr_init(&a);
        switch (pthread_attr_setscope(&a, PTHREAD_SCOPE_PROCESS))
        {
                case 0:          result = LIB_MN; break;
                case ENOTSUP:    result = LIB_11; break;
                case ENOSYS:     result = NO_PRIO_OPTION; break;
                default:         result = ERROR; break;
        }

        pthread_attr_destroy(&a);
        return result;
}

Impacts of contention scope on scheduling

The contention scope of a thread influences its scheduling. Each contention-scope thread is bound to one kernel thread. Thus, changing the scheduling policy and priority of a global user thread results in changing the scheduling policy and priority of the underlying kernel thread.

In AIX®, only kernel threads with root authority can use a fixed-priority scheduling policy (FIFO or round-robin). The following code will always return the EPERM error code if the calling thread has system contention scope but does not have root authority. This code would not fail, if the calling thread had process contention scope.

schedparam.sched_priority = 3;
pthread_setschedparam(pthread_self(), SCHED_FIFO, schedparam);

Note: Root authority is not required to control the scheduling parameters of user threads having process contention scope.

Local user threads can set any scheduling policy and priority, within the valid range of values. However, two threads having the same scheduling policy and priority but having different contention scope will not be scheduled in the same way. Threads having process contention scope are executed by kernel threads whose scheduling parameters are set by the library.