RTEMSSystemEvents

From RTEMSWiki
(Difference between revisions)
Jump to: navigation, search
(New page.)
 
Line 8: Line 8:
  
 
Various APIs include an event set as an object independent of tasks.  The first step of this project is to propose a set of operations based upon existing practice.
 
Various APIs include an event set as an object independent of tasks.  The first step of this project is to propose a set of operations based upon existing practice.
 +
 +
Some possibilities for further investigation:
 +
* FreeBSD: kqueue, kevent, taskqueue
 +
** http://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2
 +
**  http://www.freebsd.org/cgi/man.cgi?query=taskqueue&sektion=9

Revision as of 18:20, 23 February 2012

Contact: Chris Johns or Joel Sherrill

The Classic RTEMS API Event interface is a user API that provides a efficient task synchronisation. This user API is also used by RTEMS system tasks such as the networking tasks and the libblock cache. These RTEMS services have taken event numbers and use them to wake a blocked task waiting on a specific resource. In the networking task this could be the reception of a packet and in the libblock cache once a block of data has been read into memory. If the task is internal to the service being provided there is no problem how-ever where the task is a user one there are possible problems. A blocked user task may be woken by another user task that happened to send the same event. This would upset the RTEMS service and make it look like a bug that is complex to find. Typically this is avoided in current application because the user is aware of the issue or uses an event number lower down. RTEMS needs a cleaner solution to this issue.

The project is to add a new "system" Event API for RTEMS system services. The API would be the same as current Event API and the services would be defined and use restricted to that service. If a user uses this API and a service for another use that would be considered a bug so no runtime checking is required. It is hoped the current Super Core code would be used with a different event bit map from the task control block and the current RTEMS services would be updated with a new API call and event.

Various APIs include an event set as an object independent of tasks. The first step of this project is to propose a set of operations based upon existing practice.

Some possibilities for further investigation:

Personal tools
Namespaces

Variants
Actions
Navigation
Gedare's Special Help
Toolbox