This is the mail archive of the
mailing list for the glibc project.
Re: Race unlocking-locking mutex
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Godmar Back <godmar at gmail dot com>
- Cc: "Carlos O'Donell" <carlos at systemhalted dot org>, David Ahern <dsahern at gmail dot com>, "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Fri, 13 Sep 2013 13:21:39 -0400
- Subject: Re: Race unlocking-locking mutex
- Authentication-results: sourceware.org; auth=none
- References: <5231ECBE dot 4030006 at gmail dot com> <CAB4+JY+dBDVhk9UJWXRXrxF5BhoTFXv==_v+ibdEBU5Noj4aEw at mail dot gmail dot com> <5231F2C3 dot 6080305 at gmail dot com> <CAE2sS1gp9Z5b5qoSqgBXbbL-S+_fHaL1PN7z=CfMsqSTA=7LFg at mail dot gmail dot com> <CAB4+JY++Zs_kKN32oWKvy1i-HQOHZQsosBSUBc3=YrXA_S96Hw at mail dot gmail dot com>
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"
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.