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

Cosmetic cleanup from SIGCHLD changes

Browse Source 
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@5514 42af7a65-404d-4744-a932-0658087f49c3
This commit is contained in:
patacongo 2013-01-13 00:35:47 +00:00
parent 3f0b723b7c
commit 5ddbdd9ee9
2 changed files with 5 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
ChangeLog
View File

@ -3918,7 +3918,7 @@
the scenario: (1) sched_lock() is called increments the lockcount
on the current TCB (i.e., the one at the head of the ready to run
list), (2) sched_mergepending is called which may change the task
at the head of the readytorun list, then (2) sched_lock() is called
at the head of the readytorun list, then (2) sched_unlock() is called
which decrements the lockcount on the wrong TCB. The failure case
that I saw was that pre-emption got disabled in the IDLE thread,
locking up the whole system.

6
sched/task_deletecurrent.c
View File

@ -115,9 +115,12 @@ int task_deletecurrent(void)
* does not correspond to the thread that is running. Disabling pre-
* emption on this TCB and marking the new ready-to-run task as not
* running (see, for example, get_errno_ptr()).
*
* We disable pre-emption here by directly incrementing the lockcount
* (vs. calling sched_lock()).
*/
sched_lock();
rtcb->lockcount++;
rtcb->task_state = TSTATE_TASK_READYTORUN;
/* Move the TCB to the specified blocked task list and delete it */
@ -143,7 +146,6 @@ int task_deletecurrent(void)
* the lockcount on rctb.
*/
DEBUGASSERT(rtcb->lockcount > 0);
rtcb->lockcount--;
return OK;
}