sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update TODO list

Browse Source
This commit is contained in:
Gregory Nutt 2016-11-02 18:31:22 -06:00
parent 82de137012
commit 470c692dbf
1 changed files with 12 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
TODO
View File

@ -1,4 +1,4 @@
NuttX TODO List (Last updated October 9, 2016)
NuttX TODO List (Last updated November 2, 2016)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This file summarizes known NuttX bugs, limitations, inconsistencies with
@ -217,13 +217,14 @@ o Task/Scheduler (sched/)
Priority: Medium-ish
Title: ISSUES WITH PRIORITY INHERITANCE WHEN SEMAPHORE USED AS IPC
Description: The semaphores have multiple uses. The typical usage is where
Description: Semaphores have multiple uses. The typical usage is where
the semaphore is used as lock on one or more resources. In
this typical case, priority inheritance works perfectly: The
holder of a semaphore count must be remembered so that its
priority can be boosted if a higher priority task requires a
count from the semaphore. It remains the holder until is
calls sem_post() to release the count on the semaphore.
count from the semaphore. It remains the holder until the
same task calls sem_post() to release the count on the
semaphore.
But a different usage model for semaphores is for signalling
events. In this case, the semaphore count is initialized to
@ -237,11 +238,14 @@ o Task/Scheduler (sched/)
TASK B (or perhaps an interrupt handler) signals task A of
the occurence of the events by posting the semaphore:
---------------------- ---------------
TASK A TASK B
---------------------- ---------------
sem_init(sem, 0, 0);
sem_wait(sem);
sem_post(sem);
Awakens as holder
---------------------- ---------------
These two usage models are really very different and priority
inheritance simply does not apply when the semaphore is used for
@ -249,12 +253,13 @@ o Task/Scheduler (sched/)
priority inheritance can interfere with the operation of the
semaphore. The problem is that when TASK A is awakened it is
a holder of the semaphore. Normally, a task is removed from
the holder list when it finally release the
the holder list when it finally releases the semaphore via
sem_post().
However, TASK A never calls sem_post(sem) so it becomes
*permanently* a holder of the semaphore and may have its
priority boosted when any other task tries to acquire the
semaphore.
priority boosted at any time when any other task tries to
acquire the semaphore.
The fix is to call sem_setprotocol(SEM_PRIO_NONE) immediately
after the sem_init() call so that there will be no priority