This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Race unlocking-locking mutex

On 09/13/2013 09:53 AM, Godmar Back wrote:
> BTW, I checked 1003.1 the 2008 version.
> It says:

This is a long and complex topic...

> "The pthread_mutex_unlock() function shall release the mutex object 
> referenced by mutex. The manner in which a mutex is released is
> dependent upon the mutex’s type attribute. If there are threads
> blocked on the mutex object referenced by mutex when 
> pthread_mutex_unlock() is called, resulting in the mutex becoming
> available, the scheduling policy shall determine which thread shall
> acquire the mutex."
> In other words, SCHED_FIFO & SCHED_RR scheduled threads will provide 
> the necessary behavior.

I don't follow. Could you please describe in detail how they would
help this scenario?

In SCHED_FIFO the running thread1 releases the mutex, the next thread2
in the queue is made runnable (SCHED_FIFO->2 req. forces it to the
tail of the thread list) but it has no CPU yet, and eventually finds
the mutex taken by thread1 again. The SCHED_FIFO scheduling policy
does not require preemption.

The only way SCHED_FIFO and SCHED_RR help is if thread2 has a higher
priority and preempts thread1, and that makes sense and would probably
solve this problem. However, the crux of this problem is that we are
talking about fairness surrounding two threads of the same priority.

There is no notion of fair here.

> Does GNU Libc implement that?

Yes, glibc does support SCHED_FIFO and SCHED_RR, but the Linux
kernel defaults don't always conform exactly to the POSIX semantics.

In particular Linux only supports PTHREAD_SCOPE_SYSTEM, that is to
say that all threads compete with all other threads and the sched_*
functions are therefore mostly no-ops (baring bug 14829).

See: "Thread Scheduling Attributes"
For application threads with scheduling allocation domains of 
size greater than one, the rules defined for SCHED_FIFO, 
SCHED_RR, [TSP] [Option Start]  and SCHED_SPORADIC [Option End] 
shall be used in an implementation-defined manner. Each thread 
with system scheduling contention scope competes for the 
processors in its scheduling allocation domain in an 
implementation-defined manner according to its priority. 
Threads with process scheduling contention scope are scheduled 
relative to other threads within the same scheduling contention
scope in the process.

As you can see SCHED_FIFO and SCHED_RR have no real effect on
thread scheduling when in system contention scope, and therefore
can't easily be used to solve this problem. This problem is solved
by priority and preemption.

On top of this the API for scheduling allocation domains is left
blank by POSIX. AFAIK on Linux we have one scheduling allocation
domain with all CPUs in it. If you have more than 1 CPU e.g. SMP,
then it's implementation-defined how the scheduling rules are used.
It might be said the sched_setaffinity and sched_getaffinity can
be used to create pseudo-"scheduling allocation domains", but the
rules are not clear on this and you would have to control all the
processes/threads on the system to stay off a given cpu.

See also: "Scheduling Policies"

Related bugs:
Bug 14829 - sched_* functions wrongly alter thread scheduling, rather than process

Bug 15088 - glibc wrongly defines _POSIX_PRIORITY_SCHEDULING

Bug 7007 - PTHREAD_EXPLICIT_SCHED not honored after 'attr' is initialized to defaults

As you can see there is a lot of room for improvement in Linux
and glibc over thread/process scheduling.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]