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

Update TODO list and comments in aio files

Browse Source
This commit is contained in:
Gregory Nutt 2014-10-04 17:47:54 -06:00
parent 53532eed67
commit 3bef2b7a43
3 changed files with 82 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
TODO
View File

@ -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/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

31
libc/aio/aio_read.c
View File

@ -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.

31
libc/aio/aio_write.c
View File

@ -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.
* - 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.