diff options
author | Gregory Nutt <gnutt@nuttx.org> | 2014-12-13 08:44:28 -0600 |
---|---|---|
committer | Gregory Nutt <gnutt@nuttx.org> | 2014-12-13 08:44:28 -0600 |
commit | 7e91f8810fdd60503d351af80ed91c5d4e31ca91 (patch) | |
tree | 6e279e2013bc99e610e3345bac7ae4f7b37795e5 | |
parent | 9a632705357ece9571855f8be8f4c23f34629e52 (diff) | |
download | nuttx-7e91f8810fdd60503d351af80ed91c5d4e31ca91.tar.gz nuttx-7e91f8810fdd60503d351af80ed91c5d4e31ca91.tar.bz2 nuttx-7e91f8810fdd60503d351af80ed91c5d4e31ca91.zip |
Update TODO list and add REVISIT comment
-rw-r--r-- | nuttx/TODO | 45 | ||||
-rw-r--r-- | nuttx/drivers/serial/serial.c | 7 |
2 files changed, 50 insertions, 2 deletions
diff --git a/nuttx/TODO b/nuttx/TODO index 8ec8533ef..251279d27 100644 --- a/nuttx/TODO +++ b/nuttx/TODO @@ -8,7 +8,7 @@ board port. nuttx/ - (10) Task/Scheduler (sched/) + (11) Task/Scheduler (sched/) (1) Memory Managment (mm/) (3) Signals (sched/, arch/) (2) pthreads (sched/) @@ -173,6 +173,49 @@ o Task/Scheduler (sched/) Status: Open Priority: Low and not easily removable. + Title: RELEASE SEMAPHORES HELD BY CANCELED THREADS: + Description: Commit: fecb9040d0e54baf14b729e556a832febfe8229e: "In + case a thread is doing a blocking operation (e.g. read()) + on a serial device, while it is being terminated by + pthread_cancel(), then uart_close() gets called, but + the semaphore (dev->recv.sem in the above example) is + still blocked. + + "This means that once the serial device is opened next + time, data will arrive on the serial port (and driver + interrupts handled as normal), but the received characters + never arrive in the reader thread. + + This patch addresses the problem by re-initializing the + semaphores on the last uart_close() on the device." + + Yahoo! Groups message 7726: "I think that the system + should be required to handle pthread_cancel safely in + all cases. In the NuttX model, a task is like a Unix + process and a pthread is like a Unix thread. Cancelling + threads should always be safe (or at least as unsafe) as + under Unix because the model is complete for pthreads... + + "So, in my opinion, this is a generic system issue, not + specific to the serial driver. I could also implement + logic to release all semaphores held by a thread when + it exits -- but only if priority inheritance is enabled; + because only in that case does the code have any memory + of which threads actually hold the semaphore. + + "The patch I just incorporated is also insufficient. It + works only if the serial driver is shut down when the + thread is cancelled. But what if there are other open + references to the driver? Then the driver will not be + shut down, the semaphores will not be re-initialized, and + the semaphore counts will still be off by one. + + "I think that the system needs to automatically release any + semaphores held by a thread being killed asynchronously? + It seems necessary to me." + Status: Open + Priority: Medium-ish + o Memory Managment (mm/) ^^^^^^^^^^^^^^^^^^^^^^ diff --git a/nuttx/drivers/serial/serial.c b/nuttx/drivers/serial/serial.c index 3ae4bd2e4..4d40527fe 100644 --- a/nuttx/drivers/serial/serial.c +++ b/nuttx/drivers/serial/serial.c @@ -1121,7 +1121,12 @@ static int uart_close(FAR struct file *filep) /* We need to re-initialize the semaphores if this is the last close * of the device, as the close might be caused by pthread_cancel() of - * a thread currently blocking on any of them + * a thread currently blocking on any of them. + * + * REVISIT: This logic *only* works in the case where the cancelled + * thread had the only reference to the serial driver. If there other + * references, then the this logic will not be executed and the + * semaphore count will still be incorrect. */ sem_reinit(&dev->xmitsem, 0, 0); |