[Bug 1241] New: Semaphore lost during requeueing due to priority inheritance

[rtems-bugs at rtems.org]

http://www.rtems.org/bugzilla/show_bug.cgi?id=1241

           Summary: Semaphore lost during requeueing due to priority
                    inheritance
           Product: RTEMS
           Version: 4.5
          Platform: All
        OS/Version: RTEMS
            Status: NEW
          Severity: major
          Priority: P3
         Component: misc
        AssignedTo: joel.sherrill at oarcorp.com
        ReportedBy: johan.zandin at space.se


In the following scenario, the S semaphore is never recieved by Task 2. This
causes both tasks (and any other tasks requesting the R semaphore) to wait
indefinitely:
1. Task 1 has higher priority than Task 2, S is a synchronization semaphore
(simple binary semaphore with tasks wait by fifo) and R is a resource semaphore
(binary semaphore with tasks wait by priority and priority inheritance).
2. Task 2 has locked R and is waiting for S.
3. Task 1 tries to lock R, which increases the priority of Task 2.
4. When_Thread_Change_priority execute in the unprotected region around the
call to _Thread_queue_Requeue, it is interrupted by an ISR signalling S.

Cause:
The read-modify-write of current_state (on the lines surrounding the
unprotected region) can't handle that current_state is updated within the
unprotected region, (due to the signaling of S).
Also, there seems to be a similar problem within _Thread_queue_Requeue, where
interrupts are enabled while the task is temporarily outside of the queue. If S
is signaled at that occasion, it may give similar symptoms. But note that this
branch of the code will only be reached if tasks wait on S by priority.


-- 
Configure bugmail: http://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.