diff options
| -rw-r--r-- | nuttx/TODO | 35 | ||||
| -rw-r--r-- | nuttx/libc/aio/aio_read.c | 31 | ||||
| -rw-r--r-- | nuttx/libc/aio/aio_write.c | 33 |
3 files changed, 83 insertions, 16 deletions
diff --git a/nuttx/TODO b/nuttx/TODO index 93c65695b..aa3948fc7 100644 --- a/nuttx/TODO +++ b/nuttx/TODO @@ -18,7 +18,7 @@ nuttx/ (13) Network (net/, drivers/net) (4) USB (drivers/usbdev, drivers/usbhost) (10) Libraries (libc/, ) - (11) File system/Generic drivers (fs/, drivers/) + (12) File system/Generic drivers (fs/, drivers/) (6) Graphics subystem (graphics/) (1) Pascal add-on (pcode/) (1) Documentation (Documentation/) @@ -1163,6 +1163,39 @@ o File system / Generic drivers (fs/, drivers/) Status: Open Priority: Medium + Title: ASYNCHRONOUS IMPLEMENTATION ISSUES + Description: The POSIX specification of asynchronous I/O implies that a + thread is created for each I/O operation. The standard + requires that if prioritized I/O is supported for this file, + then the asynchronous operation will be submitted at a + priority equal to a base scheduling priority minus + aiocbp->aio_reqprio. If Thread Execution Scheduling is not + supported, then the base scheduling priority is that of the + calling thread. + + My initial gut feeling is the creating a new thread on each + asynchronous I/O operation would not be a good use of resources + in a deeply embedded system. So I decided to execute all + asynchronous I/O on a low-priority or user-space worker + thread. There are two negative consequences of this decision + that need to be revisited: + + 1) The worker thread runs at a fixed priority making it + impossible to meet the POSIX requirement for asynchronous + I/O. That standard specifically requires varying priority. + 2) On the worker thread, each I/O will still be performed + synchronously, one at a time. This is not a violation of + the POSIX requirement, but one would think there could be + opportunities for concurrent I/O. + + In reality, in a small embedded system, there will probably + only be one real file system and, in this case, the I/O will + be performed sequentially anyway. Most simple embedded + hardware will not support any concurrent accesses. + Status: Open + Priority: Low, I think. In fact the current solution might be the + correct one but this issue still needs to be tracked. + o Graphics subystem (graphics/) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/nuttx/libc/aio/aio_read.c b/nuttx/libc/aio/aio_read.c index 49d5823bf..82f5bb873 100644 --- a/nuttx/libc/aio/aio_read.c +++ b/nuttx/libc/aio/aio_read.c @@ -222,14 +222,31 @@ static void aio_read_worker(FAR void *arg) * description associated with aiocbp->aio_fildes. * * POSIX Compliance: - * - The standard requires that if prioritized I/O is supported for this - * file, then the asynchronous operation will be submitted at a priority - * equal to a base scheduling priority minus aiocbp->aio_reqprio. If - * Thread Execution Scheduling is not supported, then the base scheduling - * priority is that of the calling thread. + * - The POSIX specification of asynchronous I/O implies that a thread is + * created for each I/O operation. The standard requires that if + * prioritized I/O is supported for this file, then the asynchronous + * operation will be submitted at a priority equal to a base scheduling + * priority minus aiocbp->aio_reqprio. If Thread Execution Scheduling is + * not supported, then the base scheduling priority is that of the calling + * thread. * - * This implementation uses the NuttX work queues that run at a fixed, - * configured priority. + * My initial gut feeling is the creating a new thread on each asynchronous + * I/O operation would not be a good use of resources in a deeply embedded + * system. So I decided to execute all asynchronous I/O on a low-priority + * or user-space worker thread. There are two negative consequences of this + * decision that need to be revisited: + * + * 1) The worker thread runs at a fixed priority making it impossible to + * meet the POSIX requirement for asynchronous I/O. That standard + * specifically requires varying priority. + * 2) On the worker thread, each I/O will still be performed synchronously, + * one at a time. This is not a violation of the POSIX requirement, + * but one would think there could be opportunities for concurrent I/O. + * + * In reality, in a small embedded system, there will probably only be one + * real file system and, in this case, the I/O will be performed sequentially + * anyway. Most simple embedded hardware will not support any concurrent + * accesses. * * - Most errors required in the standard are not detected at this point. * There are no pre-queuing checks for the validity of the operation. diff --git a/nuttx/libc/aio/aio_write.c b/nuttx/libc/aio/aio_write.c index b8826afb9..eb8676eea 100644 --- a/nuttx/libc/aio/aio_write.c +++ b/nuttx/libc/aio/aio_write.c @@ -255,14 +255,31 @@ static void aio_write_worker(FAR void *arg) * with aiocbp->aio_fildes. * * POSIX Compliance: - * - The standard requires that if prioritized I/O is supported for this - * file, then the asynchronous operation will be submitted at a priority - * equal to a base scheduling priority minus aiocbp->aio_reqprio. If - * Thwrite Execution Scheduling is not supported, then the base scheduling - * priority is that of the calling thread. - * - * This implementation uses the NuttX work queues that run at a fixed, - * configured priority. + * - The POSIX specification of asynchronous I/O implies that a thread is + * created for each I/O operation. The standard requires that if + * prioritized I/O is supported for this file, then the asynchronous + * operation will be submitted at a priority equal to a base scheduling + * priority minus aiocbp->aio_reqprio. If Thread Execution Scheduling is + * not supported, then the base scheduling priority is that of the calling + * thread. + * + * My initial gut feeling is the creating a new thread on each asynchronous + * I/O operation would not be a good use of resources in a deeply embedded + * system. So I decided to execute all asynchronous I/O on a low-priority + * or user-space worker thread. There are two negative consequences of this + * decision that need to be revisited: + * + * 1) The worker thread runs at a fixed priority making it impossible to + * meet the POSIX requirement for asynchronous I/O. That standard + * specifically requires varying priority. + * 2) On the worker thread, each I/O will still be performed synchronously, + * one at a time. This is not a violation of the POSIX requirement, + * but one would think there could be opportunities for concurrent I/O. + * + * In reality, in a small embedded system, there will probably only be one + * real file system and, in this case, the I/O will be performed sequentially + * anyway. Most simple embedded hardware will not support any concurrent + * accesses. * * - Most errors required in the standard are not detected at this point. * There are no pre-queuing checks for the validity of the operation. |