Incorrect SCHED_FIFO priority handling

Bug #670670 reported by Matthew Grochowalski
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
eglibc (Ubuntu)
New
Undecided
Unassigned

Bug Description

Binary package hint: libc6

I’m using 10.04. I'm also seeing this on 10.10.
Using SCHED_FIFO, temporarily raising a thread's priority then lowering it back to the original priority using mutexes with priority ceilings and sched_setprio should cause the task to stay at the head of the queue for it's priority. This is defined in the POSIX standards and the Linux manpages.
However, I'm seeing the task running for a while then incorrectly being preempted by another task of the same priority.
pthread_setschedparam also exhibits this behavior, even though that should always insert tasks at the back of the queue for their priority. I've also seen this behavior by using pthread_setschedprio to set a task to the priority it currently has, which should do nothing.

I have attached an example of this problem using mutexes with priority ceilings.
Expected behavior: The loop in highThread runs until sLoop hits 0xFFFFFFFF
Actual behavior: highThread is preempted by mediumThread in the middle of the loop.

Revision history for this message
Matthew Grochowalski (matthew-grochowalski) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.