Newer
Older
<head>
<title>NuttX Users Manual</title>
<meta name="AUTHOR" content="Gregory Nutt">
</head>
<body background="backgd.gif">
<hr>
<hr>
<center><h1><i>Under Construction</i></h1></center>
<hr>
<hr>
NuttX Operating System
<small>Last Update: March 28, 2007</small>
</center>
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
<h1>1.0 <A NAME="Introduction">Introduction</a></h1>
<p>
This manual provides general usage information for the NuttX RTOS from the
perspective of the firmware developer.
<h2>1.1 <a name="overview">Document Overview</a></h2>
<p>
This user's manual is divided into three sections plus a index:
</p>
<ul>
<li>
<b>Section 1.0, <a href="#Introduction">Introduction</a></b>:
This section provides an overview of the NuttX user's manual.
</li>
<li>
<b>Section 2.0, <a href="#OS_Interfaces">OS Interfaces</a></b>:
This section details the program interfaces provided by NuttX.
This section is divided into several paragraphs that describe different groups of OS interfaces:
<ul>
<li>Paragraph 2.1 <a href="#Task_Control">Task Control Interfaces</a></li>
<li>Paragraph 2.2 <a href="#Task_Schedule">Task Scheduling Interfaces</a></li>
<li>Paragraph 2.3 <a href="#Task_Switch">Task Switching Interfaces</a></li>
<li>Paragraph 2.4 <a href="#Message_Queue">Named Message Queue Interfaces</a></li>
<li>Paragraph 2.5 <a href="#Semaphores">Counting Semaphore Interfaces</a></li>
<li>Paragraph 2.6 <a href="#Watchdogs">Watchdog Timer Interfaces</a></li>
<li>Paragraph 2.7 <a href="#ClocksNTimers">Clocks and Timers</a></li>
<li>Paragraph 2.8 <a href="#Signals">Signal Interfaces</a></li>
<li>Paragraph 2.9 <a href="#Pthread">Pthread Interfaces</a></li>
<li>Paragraph 2.10 <a href="#FileSystem">Filesystem Interfaces</a></li>
</ul>
</li>
<li>
<b>Section 3.0, <a href="#Data_Structures">OS Data Structures</a></b>:
This section documents the data structures that are used at the NuttX
interface.
</li>
<li>
<a href="#index">Index</a>
</li>
</ul>
<h2>1.2 <a name="scope">Intended Audience and Scope</a></h2>
<p>
The intended audience for this document are firmware developers who are implementing applications on NuttX.
Specifically, this documented is limited to addressing only NuttX RTOS APIs that are available to the application developer.
As such, this document does not focus on any technical details of the organization or implementation of NuttX.
Those technical details are provided in the <a href="NuttxPortingGuide.html">NuttX Porting Guide</a>.
</p>
<p>
Information about configuring and building NuttX is also needed by the application developer.
That information can also be found in the <a href="NuttxPortingGuide.html#configandbuild">NuttX Porting Guide</a>.
</p>
<hr>
<h1>2.0 <A NAME="OS_Interfaces">OS Interfaces</a></h1>
<p>
This section describes each C-callable interface to the NuttX
Operating System. The description of each interface is presented
in the following format:
<p>
<b>Function Prototype:</b> The C prototype of the interface function
<p>
<b>Description:</b> The operation performed by the interface function
<p>
<b>Input Parameters:</b> All input parameters are listed along
<p>
<b>Returned Values:</b> All possible values returned by the interface
function are listed. Values returned as side-effects (through
pointer input parameters or through global variables) will be
addressed in the description of the interface function.
<p>
<b>Assumptions/Limitations:</b> Any unusual assumptions made by
the interface function or any non-obvious limitations to the use
of the interface function will be indicated here.
<p>
<b>POSIX Compatibility:</b> Any significant differences between the
NuttX interface and its corresponding POSIX interface will be noted
NOTE: In order to achieve an independent name space for the NuttX
interface functions, differences in function names and types are
to be expected and will not be identified as differences in these
paragraphs.
NuttX is a flat address OS. As such it does not support <i>processes</i>
in the way that, say, Linux does.
NuttX only supports simple threads running within the same address space.
However, the programming model makes a distinction between <i>tasks</i>
and <i>pthreads</i>:
<li><i>tasks</i> are threads which have a degree of independence
<li><a href="#Pthread"><i>pthreads</i></a> share some resources.
<b>File Descriptors and Streams</b>.
This applies, in particular, in the area of opened file descriptors and streams.
When a task is started using the interfaces in this section, it will be created
with at most three open files.
</p>
</p>
If CONFIG_DEV_CONSOLE is defined, the first three file descriptors (corresponding
to stdin, stdout, stderr) will be duplicated for the the new task.
Since these file descriptors are duplicated, the child task can free close
them or manipulate them in any way without effecting the parent task.
File-related operations (open, close, etc.) within a task will have no effect
on other tasks.
Since the three file descriptors are duplicated, it is also possible to perform
some level of redirection.
</p>
<p>
pthreads, on the other hand, will always share file descriptors with the parent
thread. In this case, file operations will have effect only all pthreads the
were started from the same parent thread.
</p>
The following task control interfaces are provided by Nuttx:
</p>
<ul>
<li><a href="#taskcreate">2.1.1 task_create</a></li>
<li><a href="#taskinit">2.1.2 task_init</a></li>
<li><a href="#taskactivate">2.1.3 task_activate</a></li>
<li><a href="#taskdelete">2.1.4 task_delete</a></li>
<li><a href="#exit">2.1.5 exit</a></li>
<li><a href="#taskrestart">2.1.6 task_restart</a></li>
<li><a href="#getpid">2.1.7 getpid</a></li>
</ul>
int task_create(char *name, int priority, int stack_size, main_t entry, const char *argv[]);
This function creates and activates a new task with a
specified priority and returns its system-assigned ID.
</p>
function of the task.
This function will be called once the C environment has been set up.
The specified function will be called with four arguments.
Should the specified routine return, a call to exit() will automatically be made.
</P>
<p>
Note that an arbitrary number of arguments may be passed to the
spawned functions. The maximum umber of arguments is an OS
configuration parameter (<code>CONFIG_MAX_TASK_ARGS</code>).
</p>
<p>
The arguments are copied (via <code>strdup</code>) so that the
life of the passed strings is not dependent on the life of the
caller to <code>task_create()</code>.
</p>
<p>
The newly created task does not inherit scheduler characteristics
from the parent task: The new task is started at the
default system priority and with the SCHED_FIFO scheduling
policy. These characteristcs may be modified after the new
<p>
The newly created task does inherit the first three file
descriptors (corresponding to stdin, stdout, and stderr) and
redirection of standard I/O is supported.
</p>
<p>
<b>Input Parameters:</b>
<ul>
<li><I>name</I>. Name of the new task</LI>
<li><I>priority</I>. Priority of the new task</LI>
<li><I>stack_size</I>. size (in bytes) of the stack needed</LI>
<li><I>entry</I>. Entry point of a new task</LI>
<li><I>argv</I>. A pointer to an array of input parameters. Up to
<code>CONFIG_MAX_TASK_ARG</code> parameters may be provided.
If fewer than <code>CONFIG_MAX_TASK_ARG</code> parameters are
passed, the list should be terminated with a NULL argv[] value.
If no parameters are required, argv may be NULL.
Returns the non-zero task ID of the new task or
ERROR if memory is insufficient or the task cannot be
created (errno is not set).
</LI>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b>POSIX Compatibility:</b> This is a NON-POSIX interface.
int taskSpawn(char *name, int priority, int options, int stackSize, FUNCPTR entryPt,
int arg1, int arg2, int arg3, int arg4, int arg5,
int arg6, int arg7, int arg8, int arg9, int arg10);
The NuttX task_create() differs from VxWorks' taskSpawn() in the
following ways:
</p>
<ul>
<li>Interface name
<li>Various differences in types of arguments
<li>There is no options arguement.
<li>A variable number of parameters can be passed to a task (VxWorks supports ten).
</ul>
STATUS task_init(_TCB *tcb, char *name, int priority, uint32 *stack, uint32 stack_size,
maint_t entry, const char *argv[]);
in preparation for starting a new thread. It performs a subset
of the functionality of <code>task_create()</code> (see above).
Unlike task_create(), task_init() does not activate the task.
This must be done by calling task_activate().
</P>
<p>
<b>Input Parameters:</b>
<ul>
<li><I>tcb</I>. Address of the new task's TCB
<li><I>name</I>. Name of the new task (not used)
<li><I>priority</I>. Priority of the new task
<li><I>stack</I>. Start of the pre-allocated stack
<li><I>stack_size</I>. size (in bytes) of the pre-allocated stack
<li><I>entry</I>. Entry point of a new task
<li><I>argv</I>. A pointer to an array of input parameters. Up to
<code>CONFIG_MAX_TASK_ARG</code> parameters may be provided.
If fewer than <code>CONFIG_MAX_TASK_ARG</code> parameters are
passed, the list should be terminated with a NULL argv[] value.
If no parameters are required, argv may be NULL.
<ul>
<li><p>OK, or ERROR if the task cannot be initialized.</P>
<p>This function can only failure is it is unable to assign
</ul>
<p>
<b>Assumptions/Limitations:</b>
<ul>
<li>task_init() is provided to support internal OS functionality. It is
<b>not recommended</b> for normal usage. task_create() is the preferred
</ul>
<p>
<b>POSIX Compatibility:</b> This is a NON-POSIX interface.
STATUS taskInit(WIND_TCB *pTcb, char *name, int priority, int options, uint32 *pStackBase, int stackSize,
FUNCPTR entryPt, int arg1, int arg2, int arg3, int arg4, int arg5,
int arg6, int arg7, int arg8, int arg9, int arg10);
The NuttX task_init() differs from VxWorks' taskInit() in the
following ways:
</p>
<ul>
<li>Interface name
<li>Various differences in types or arguments
<li>There is no options argument.
<li>A variable number of parameters can be passed to a task (VxWorks supports ten).
</ul>
<p>
<b>Description:</b> This function activates tasks created by task_init().
Without activation, a task is ineligible for execution by the
scheduler.
<p>
<b>Input Parameters:</b>
<ul>
<li><I>tcb</I>. The TCB for the task for the task (same as the
</ul>
<p>
<b>Returned Values:</b>
<ul>
<li>OK, or ERROR if the task cannot be activated (errno is not set).
</ul>
<p>
<b>Assumptions/Limitations:</b>
<ul>
<li>task_activate() is provided to support internal OS functionality. It is
<b>not recommended</b> for normal usage. task_create() is the preferred
</ul>
<p>
<b>POSIX Compatibility:</b> This is a NON-POSIX interface.
The NuttX task_activate() differs from VxWorks' taskActivate() in the
following ways:
</p>
<ul>
<li>Function name
<li>With VxWork's taskActivate, the pid argument is supposed to be
<p>
<b>Description:</b> This function causes a specified task to cease
to exist -- its stack and TCB will be deallocated. This function
is the companion to task_create().
<p>
<b>Input Parameters:</b>
<ul>
<li><I>pid</I>. The task ID of the task to delete. An ID of
<p>
<b>Returned Values:</b>
<ul>
<li>OK, or ERROR if the task cannot be deleted.
This function can fail if the provided pid does not correspond to a task (errno is not set)
task_delete() must be used with caution: If the task holds resources
(for example, allocated memory or semaphores needed by other tasks), then
task_delete() can strand those resources.
The NuttX task_delete() differs from VxWorks' taskDelete() in
the following ways:
</p>
<ul>
<li>No support is provided for calling the tasks deletion routines
#include <sched.h>
void exit( int code );
#include <nuttx/unistd.h>
void _exit( int code );
<p>
<b>Description:</b> This function causes the calling task to cease
to exist -- its stack and TCB will be deallocated. exit differs from
_exit in that it flushs streams, closes file descriptors and will
execute any function registered with atexit().
<p>
<b>Input Parameters:</b>
<ul>
<li><I>code</I>. (ignored)
</ul>
<p>
<b>POSIX Compatibility:</b> This is equivalent to the ANSI interface:
The NuttX exit() differs from ANSI exit() in the following ways:
</p>
<p>
<b>Description:</b> This function "restarts" a task.
The task is first terminated and then reinitialized with same
ID, priority, original entry point, stack size, and parameters
it had when it was first started.
<p>
<b>Input Parameters:</b>
<ul>
<li><I>pid</I>. The task ID of the task to delete. An ID of
OK, or ERROR if the task ID is invalid or the task could
not be restarted.
This function can fail if:
(1) A pid of zero or the pid of the calling task is provided (functionality not implemented)
(2) The pid is not associated with any task known to the system.
</LI>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b>POSIX Compatibility:</b> This is a NON-POSIX interface.
The NuttX task_restart() differs from VxWorks' taskRestart() in the following ways:
</p>
<ul>
<li>Restart of the currently running task is not supported.
<li>The VxWorks description says that the ID, priority, etc. take
<p>
<b>Description:</b> This function returns the task ID of the
calling task. The task ID will be invalid if called at the interrupt
level.
<p>
<b>Input Parameters:</b> None.
<p>
<b>Returned Values:</b>
<ul>
<li>The task ID of the calling task.
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b>POSIX Compatibility:</b>
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
<p>
By default, NuttX performs strict priority scheduling: Tasks of higher
priority have exclusive access to the CPU until they become blocked.
At that time, the CPU is available to tasks of lower priority.
Tasks of equal priority are scheduled FIFO.
</p>
<p>
Optionally, a Nuttx task or thread can be configured with round-robin
scheduler. This is similar to priority scheduling <i>except</i> that
tasks with equal priority and share CPU time via <i>time-slicing</i>.
The time-slice interval is a constant determined by the configuration
setting <code>CONFIG_RR_INTERVAL</code>.
</p>
<p>
The OS interfaces described in the following paragraphs provide
a POSIX- compliant interface to the NuttX scheduler:
</p>
<ul>
<li><a href="#schedsetparam">2.2.1 sched_setparam</a></li>
<li><a href="#schedgetparam">2.2.2 sched_getparam</a></li>
<li><a href="#schedsetscheduler">2.2.3 sched_setscheduler</a></li>
<li><a href="#setgetscheduler">2.2.4 sched_getscheduler</a></li>
<li><a href="#sched_yield">2.2.5 sched_yield</a></li>
<li><a href="#schedgetprioritymax">2.2.6 sched_get_priority_max</a></li>
<li><a href="#schedgetprioritymin">2.2.7 sched_get_priority_min</a></li>
<li><a href="#schedgetrrinterval">2.2.8 sched_get_rr_interval</a></li>
</ul>
int sched_setparam(pid_t pid, const struct sched_param *param);
</pre>
<p>
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
This function sets the priority of the task specified by pid input parameter.
</p>
<p>
NOTE: Setting a task's priority to the same value has the similar
effect to <code>sched_yield()</code>: The task will be moved to after all
other tasks with the same priority.
</p>
<p>
<b>Input Parameters:</b>
</p>
<ul>
<li>
<code>pid</code>.
The task ID of the task.
If <code>pid</code> is zero, the priority of the calling task is set.
</li>
<li>
<code>param</code>.
A structure whose member <code>sched_priority</code> is the integer priority.
The range of valid priority numbers is from <code>SCHED_PRIORITY_MIN</code> through <code>SCHED_PRIORITY_MAX</code>.
</li>
</ul>
<p>
<b>Returned Values:</b>
On success, sched_setparam() returns 0 (OK).
On error, -1 (ERROR) is returned, and errno is set appropriately.
</p>
<ul>
<li>
<code>EINVAL</code>.
The parameter <code>param</code> is invalid or does not make sense for the current scheduling policy.
</li>
<li>
<code>EPERM</code>.
The calling task does not have appropriate privileges.
</li>
<li>
<code>ESRCH</code>.
The task whose ID is <code>pid</code> could not be found.
</li>
</ul>
<p>
<b>Assumptions/Limitations:</b>
</p>
<p>
Comparable to the POSIX interface of the same name.
Differences from the full POSIX implementation include:
</p>
<ul>
<li>The range of priority values for the POSIX call is 0 to 255.</li>
</ul>
#include <sched.h>
int sched_getparam (pid_t pid, struct sched_param *param);
<p>
<b>Description:</b> This function gets the scheduling priority
<p>
<b>Input Parameters:</b>
<ul>
<li>
<code>pid</code>. The task ID of the task.
If pid is zero, the priority of the calling task is returned.
</li>
<li>
<code>param</code>.
A structure whose member <code>sched_priority</code> is the integer priority.
The task's priority is copied to the <code>sched_priority</code> element of this structure.
</li>
</ul>
<p>
<b>Returned Values:</b>
<ul>
<li>0 (OK) if successful, otherwise -1 (ERROR).
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
<H3><a name="schedsetscheduler">2.2.3 sched_setscheduler</a></H3>
#include <sched.h>
int sched_setscheduler (pid_t pid, int policy, const struct sched_param *param);
<i>sched_setscheduler()</i> sets both the scheduling policy
and the priority for the task identified by pid.
If pid equals zero, the scheduler of the calling
thread will be set.
The parameter 'param' holds the priority of the thread under the new policy.
</p>
<p>
<b>Input Parameters:</b>
<ul>
<li>
<I>pid</I>. The task ID of the task. If pid is zero, the
</li>
<li>
<I>policy</I>. Scheduling policy requested (either SCHED_FIFO or SCHED_RR).
</li>
<li>
<code>param<code>. A structure whose member sched_priority is the
integer priority. The range of valid priority numbers is from
SCHED_PRIORITY_MIN through SCHED_PRIORITY_MAX.
On success, <i>sched_setscheduler()</i> returns OK (zero). On
error, ERROR (-1) is returned, and errno is set appropriately:
</p>
<ul>
<li>EINVAL The scheduling policy is not one of the
recognized policies.</li>
<li>ESRCH The task whose ID is pid could not be found.</li>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
pid equals zero, the policy of the calling process will
be retrieved.
*
* Inputs:
*
* Return Value:
This function returns the current scheduling
policy.
The task ID of the task to query.
If pid is zero, the calling task is queried.
</LI>
On success, <i>sched_getscheduler()</i> returns the policy for
the task (either SCHED_FIFO or SCHED_RR).
On error, ERROR (-1) is returned, and errno is set appropriately:
<ul>
<li>ESRCH The task whose ID is pid could not be found.</li>
</ul>
</li>
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
interface of the same name.
Differences from the full POSIX implementation include:
<p>
<b>Description:</b> This function forces the calling task to give
<p>
<b>Input Parameters:</b> None.
<p>
<b>Returned Values:</b>
<ul>
<li>0 (OK) or -1 (ERROR)
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
<H3><a name="schedgetprioritymax">2.2.6 sched_get_priority_max</a></H3>
#include <sched.h>
int sched_get_priority_max (int policy)
<p>
<b>Description:</b> This function returns the value of the highest
<p>
<b>Input Parameters:</b>
<ul>
<li><I>policy</I>. Scheduling policy requested.
</ul>
<p>
<b>Returned Values:</b>
<ul>
<li>The maximum priority value or -1 (ERROR).
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
<H3><a name="schedgetprioritymin">2.2.7 sched_get_priority_min</a></H3>
#include <sched.h>
int sched_get_priority_min (int policy);
<p>
<b>Description:</b> This function returns the value of the lowest
<p>
<b>Input Parameters:</b>
<ul>
<li><I>policy</I>. Scheduling policy requested.
</ul>
<p>
<b>Returned Values:</b>
<ul>
<li>The minimum priority value or -1 (ERROR)
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
<H3><a name="schedgetrrinterval">2.2.8 sched_get_rr_interval</a></H3>
#include <sched.h>
int sched_get_rr_interval (pid_t pid, struct timespec *interval);
<i>sched_rr_get_interval()</i> writes the timeslice interval
for task identified by <i>pid</i> into the timespec structure
pointed to by <i>interval</i>. If pid is zero, the timeslice
for the calling process is written into 'interval. The
identified process should be running under the SCHED_RR
scheduling policy.'
</p>
<ul>
<li><I>pid</I>. The task ID of the task. If pid is zero, the
<li><I>interval</I>. A structure used to return the time slice.
</ul>
On success, sched_rr_get_interval() returns OK (0). On
error, ERROR (-1) is returned, and errno is set to:
</p>
<ul>
<li>EFAULT Cannot copy to interval</LI>
<li>EINVAL Invalid pid.</LI>
<li>ENOSYS The system call is not yet implemented.</LI>
<li>ESRCH The process whose ID is pid could not be found.</LI>
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b>POSIX Compatibility:</b> Comparable to the POSIX
<ul>
<li><a href="#schedlock">2.3.1 sched_lock</a></li>
<li><a href="#schedunlock">2.3.2 sched_unlock</a></li>
<li><a href="#schedlockcount">2.3.3 sched_lockcount</a></li>
</ul>
<H3><a name="schedlock">2.3.1 sched_lock</a></H3>
<p>
<b>Description:</b> This function disables context switching by
Disabling addition of new tasks to the ready-to-run task list.
The task that calls this function will be the only task that is
allowed to run until it either calls sched_unlock (the appropriate
number of times) or until it blocks itself.
<p>
<b>Input Parameters:</b> None.
<p>
<b>Returned Values:</b>
<ul>
<li>OK or ERROR.
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> This is a NON-POSIX interface.
<p>
<b>Description:</b> This function decrements the preemption lock
count. Typically this is paired with sched_lock() and concludes
a critical section of code. Preemption will not be unlocked until
sched_unlock() has been called as many times as sched_lock().
When the lockCount is decremented to zero, any tasks that were
eligible to preempt the current task will execute.
<p>
<b>Input Parameters:</b> None.
<p>
<b>Returned Values:</b>
<ul>
<li>OK or ERROR.
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> This is a NON-POSIX interface.
<p>
<b>Description:</b> This function returns the current value of
the lockCount. If zero, preemption is enabled; if non-zero, this
value indicates the number of times that sched_lock() has been called
on this thread of execution.
<p>
<b>Input Parameters:</b> None.
<p>
<b>Returned Values:</b>
<ul>
<li>The current value of the lockCount.
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> None.
<hr>
<H2>2.4 <A NAME="Message_Queue">Named Message Queue Interfaces</a></H2>
<p>
NuttX supports POSIX named message queues for intertask communication.
Any task may send or receive messages on named message queues.
Interrupt handlers may send messages via named message queues.
</p>
<ul>
<li><a href="#mqopen">2.4.1 mq_open</a></li>
<li><a href="#mqclose">2.4.2 mq_close</a></li>
<li><a href="#mqunlink">2.4.3 mq_unlink</a></li>
<li><a href="#mqsend">2.4.4 mq_send</a></li>
<li><a href="#mqtimedsend">2.4.5 mq_timedsend</a></li>
<li><a href="#mqreceive">2.4.6 mq_receive</a></li>
<li><a href="#mqtimedreceive">2.4.7 mq_timedreceive</a></li>
<li><a href="#mqnotify">2.4.8 mq_notify</a></li>
<li><a href="#mqsetattr">2.4.9 mq_setattr</a></li>
<li><a href="#mqgetattr">2.4.10 mq_getattr</a></li>
#include <mqueue.h>
mqd_t mq_open( const char *mqName, int oflags, ... );
<p>
<b>Description:</b> This function establish a connection between
a named message queue and the calling task. After a successful
call of mq_open(), the task can reference the message queue using
the address returned by the call. The message queue remains usable
until it is closed by a successful call to mq_close().
<p>
<b>Input Parameters:</b>
<ul>
<li><I>mqName</I>. Name of the queue to open
<li><I>oflags</I>. Open flags. These may be any combination of:
<ul>
<li><I>O_RDONLY</I>. Open for read access.
<li><I>O_WRONLY</I>. Open for write access.
<li><I>O_RDWR</I>. Open for both read & write access.
<li><I>O_CREAT</I>. Create message queue if it does not already
<li><I>O_EXCL</I>. Name must not exist when opened.
<li><I>O_NONBLOCK</I>. Don't wait for data.
</ul>
When the O_CREAT flag is specified, POSIX requires that a third
and fourth parameter be supplied:
<ul>
<li><I>mode</I>. The mode parameter is of type mode_t. In the POSIX
specification, this mode value provides file permission bits for the
message queue. This parameter is required but not used in the present
implementation.
<li><I>attr</I>. A pointer to an mq_attr that is provided to initialize.
the message queue. If attr is NULL, then the messages queue is created
with implementation-defined default message queue attributes. If attr is
non-NULL, then the message queue mq_maxmsg attribute is set to the
corresponding value when the queue is created. The mq_maxmsg attribute
determines the maximum number of messages that can be queued before
addition attempts to send messages on the message queue fail or cause the
sender to block; the mq_msgsize attribute determines the maximum size of a
message that can be sent or received. Other elements of attr are ignored
(i.e, set to default message queue attributes).
</ul>
</ul>
<p>
<b>Returned Values:</b>
<ul>
<li>A message queue descriptor or -1 (ERROR)
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX interface
of the same name.
Differences from the full POSIX implementation include:
<ul>
<li>The mq_msgsize attributes determines the maximum size of a message that
may be sent or received. In the present implementation, this maximum
message size is limited at 22 bytes.
<p>
<b>Description:</b> This function is used to indicate that the
calling task is finished with the specified message queued mqdes.
The mq_close() deallocates any system resources allocated by the
system for use by this task for its message queue.
If the calling task has attached a notification request to the message
queue via this <I>mqdes</I> (see mq_notify()), this attachment will be
removed and the message queue is available for another task to attach
for notification.
<p>
<b>Input Parameters:</b>
<ul>
<li><I>mqdes</I>. Message queue descriptor.
</ul>
<p>
<b>Returned Values:</b>
<ul>
<li>0 (OK) if the message queue is closed successfully, otherwise,
<li>The behavior of a task that is blocked on either a <code>mq_send()</code> or
<code>mq_receive()</code> is undefined when <code>mq_close()</code> is called.
<li>The result of using this message queue descriptor after successful
</ul>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX interface
#include <mqueue.h>
int mq_unlink( const char *mqName );
<p>
<b>Description:</b> This function removes the message queue named
by "mqName." If one or more tasks have the message queue
open when mq_unlink() is called, removal of the message queue
is postponed until all references to the message queue have been
closed.
<p>
<b>Input Parameters:</b>
<ul>
<li><I>mqName</I>. Name of the message queue
</ul>
<p>
<b>Returned Values:</b> None.
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
int mq_send(mqd_t mqdes, const void *msg, size_t msglen, int prio);
</pre>
<b>Description:</b>
This function adds the specified message, <code>msg</code>,
to the message queue, <code>mqdes</code>.
The <code>msglen</code> parameter specifies the length of the message in bytes pointed to by <code>msg</code>.
This length must not exceed the maximum message length from the <code>mq_getattr()</code>.
</p>
If the message queue is not full, <code>mq_send()</code> will place the <code>msg</code>
in the message queue at the position indicated by the <code>prio</code> argument.
Messages with higher priority will be inserted before lower priority messages
The value of <code>prio</code> must not exceed <code>MQ_PRIO_MAX</code>.
</p>
If the specified message queue is full and <code>O_NONBLOCK</code> is not
set in the message queue, then <code>mq_send()</code> will block until space
becomes available to the queue the message.
</p>
If the message queue is full and <code>NON_BLOCK</code> is set, the message
is not queued and <code>ERROR</code> is returned.
</p>
<b>Input Parameters:</b>
</p>
<li><code>mqdes</code>. Message queue descriptor.</li>
<li><code>msg</code>. Message to send.</li>
<li><code>msglen</code>. The length of the message in bytes.</li>
<li><code>prio</code>. The priority of the message.</li>
<b>Returned Values:</b>
On success, <code>mq_send()</code> returns 0 (<code>OK</code>);
on error, -1 (<code>ERROR</code>) is returned, with <code>errno</code> set
to indicate the error:
</p>
<li>
<code>EAGAIN</code>.
The queue was empty, and the <code>O_NONBLOCK</code> flag was set for the message queue description referred to by <code>mqdes</code>.
</li>
<li>
<code>EINVAL</code>.
Either <code>msg</code> or <code>mqdes</code> is <code>NULL</code> or the value of <code>prio</code> is invalid.
</li>
<li>
<code>EPERM</code>.
Message queue opened not opened for writing.
</li>
<li>
<code>EMSGSIZE</code>.
<code>msglen</code> was greater than the <code>maxmsgsize</code> attribute of the message queue.
</li>
<li>
<code>EINTR</code>.
The call was interrupted by a signal handler.
</li>
<p>
<b>Assumptions/Limitations:</b>
</p>
<p>
<b>POSIX Compatibility:</b>
Comparable to the POSIX interface of the same name.
</p>
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
<h3><a name="mqtimedsend">mq_timedsend</a></h3>
<b>Function Prototype:</b>
</p>
<pre>
#include <mqueue.h>
int mq_timedsend(mqd_t mqdes, const char *msg, size_t msglen, int prio,
const struct timespec *abstime);
</pre>
<p>
<b>Description:</b>
This function adds the specified message, <code>msg</code>,
to the message queue, <code>mqdes</code>.
The <code>msglen</code> parameter specifies the length of the message in bytes pointed to by <code>msg</code>.
This length must not exceed the maximum message length from the <code>mq_getattr()</code>.
</p>
<p>
If the message queue is not full, <code>mq_timedsend()</code> will place the <code>msg</code>
in the message queue at the position indicated by the <code>prio</code> argument.
Messages with higher priority will be inserted before lower priority messages
The value of <code>prio</code> must not exceed <code>MQ_PRIO_MAX</code>.
</p>
<p>
If the specified message queue is full and <code>O_NONBLOCK</code> is not
set in the message queue, then <code>mq_send()</code> will block until space
becomes available to the queue the message or until a timeout occurs.
</p>
<p>
<code>mq_timedsend()</code> behaves just like <code>mq_send()</code>, except
that if the queue is full and the <code>O_NONBLOCK</code> flag is not enabled
for the message queue description, then <code>abstime</code> points to a
structure which specifies a ceiling on the time for which the call will block.
This ceiling is an absolute timeout in seconds and nanoseconds since the
Epoch (midnight on the morning of 1 January 1970).
</p>
<p>
If the message queue is full, and the timeout has already expired by the time
of the call, <code>mq_timedsend()<code> returns immediately.
</p>
<p>
<b>Input Parameters:</b>
</p>
<ul>
<li><code>mqdes</code>. Message queue descriptor.</li>
<li><code>msg</code>. Message to send.</li>
<li><code>msglen</code>. The length of the message in bytes.</li>
<li><code>prio</code>. The priority of the message.</li>
</ul>
<p>
<b>Returned Values:</b>
On success, <code>mq_send()</code> returns 0 (<code>OK</code>);
on error, -1 (<code>ERROR</code>) is returned, with <code>errno</code> set
to indicate the error:
</p>
<ul>
<li>
<code>EAGAIN</code>.
The queue was empty, and the <code>O_NONBLOCK</code> flag was set for the message queue description referred to by <code>mqdes</code>.
</li>
<li>
<code>EINVAL</code>.
Either <code>msg</code> or <code>mqdes</code> is <code>NULL</code> or the value of <code>prio</code> is invalid.
</li>
<li>
<code>EPERM</code>.
Message queue opened not opened for writing.
</li>
<li>
<code>EMSGSIZE</code>.
<code>msglen</code> was greater than the <code>maxmsgsize</code> attribute of the message queue.
</li>
<li>
<code>EINTR</code>.
The call was interrupted by a signal handler.
</li>
</ul>
<p>
<b>Assumptions/Limitations:</b>
</p>
<p>
<b>POSIX Compatibility:</b>
Comparable to the POSIX interface of the same name.
</p>
<h3><a name="mqreceive">2.4.5 mq_receive</a></h3>
<b>Function Prototype:</b>
</p>
<pre>
ssize_t mq_receive(mqd_t mqdes, void *msg, size_t msglen, int *prio);
<b>Description:</b>
This function receives the oldest of the highest priority messages from the message
queue specified by <code>mqdes</code>.
If the size of the buffer in bytes, <code>msgLen</code>, is less than the
<code>mq_msgsize</code> attribute of the message queue, <code>mq_receive()</code> will
return an error.
Otherwise, the selected message is removed from the queue and copied to <code>msg</code>.
</p>
If the message queue is empty and <code>O_NONBLOCK</code> was not set, <code>mq_receive()</code>
will block until a message is added to the message queue.
If more than one task is waiting to receive a message, only the task with the highest
priority that has waited the longest will be unblocked.
</p>
If the queue is empty and <code>O_NONBLOCK</code> is set, <code>ERROR</code> will be returned.
</p>
<b>Input Parameters:</b>
</p>
<li><code>mqdes</code>. Message Queue Descriptor.</li>
<li><code>msg</code>. Buffer to receive the message.</li>
<li><code>msglen</code>. Size of the buffer in bytes.</li>
<li><code>prio</code>. If not NULL, the location to store message priority.
<b>Returned Values:</b>.
One success, the length of the selected message in bytes is returned.
On failure, -1 (<code>ERROR</code>) is returned and the <code>errno</code> is set appropriately:
</p>
<li>
<code>EAGAIN</code>
The queue was empty and the <code>O_NONBLOCK</code> flag was set for the message queue description referred to by <code>mqdes</code>.
</li>
<li>
<code>EPERM</code>
Message queue opened not opened for reading.
</li>
<li>
<code>EMSGSIZE</code>
<code>msglen</code> was less than the <code>maxmsgsize</code> attribute of the message queue.
</li>
<li>
<code>EINTR</code>
The call was interrupted by a signal handler.
</li>
<li>
<code>EINVAL</code>
Invalid <code>msg</code> or <code>mqdes</code>
</li>
<b>Assumptions/Limitations:</b>
</p>
<b>POSIX Compatibility:</b>
Comparable to the POSIX interface of the same name.
</p>
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
<h3><a name="mqtimedreceive">2.4.6 mq_timedreceive</a></h3>
<p>
<b>Function Prototype:</b>
</p>
<pre>
#include <mqueue.h>
ssize_t mq_timedreceive(mqd_t mqdes, void *msg, size_t msglen,
int *prio, const struct timespec *abstime);
</pre>
<p>
<b>Description:</b>
This function receives the oldest of the highest priority messages from the message
queue specified by <code>mqdes</code>.
If the size of the buffer in bytes, <code>msgLen</code>, is less than the
<code>mq_msgsize</code> attribute of the message queue, <code>mq_timedreceive()</code> will
return an error.
Otherwise, the selected message is removed from the queue and copied to <code>msg</code>.
</p>
<p>
If the message queue is empty and <code>O_NONBLOCK</code> was not set, <code>mq_timedreceive()</code>
will block until a message is added to the message queue (or until a timeout occurs).
If more than one task is waiting to receive a message, only the task with the highest
priority that has waited the longest will be unblocked.
</p>
<p>
<code>mq_timedreceive()</code> behaves just like <code>mq_receive()<code>, except
that if the queue is empty and the <code>O_NONBLOCK<c/ode> flag is not enabled
for the message queue description, then <code>abstime</code> points to a structure
which specifies a ceiling on the time for which the call will block.
This ceiling is an absolute timeout in seconds and nanoseconds since the Epoch
(midnight on the morning of 1 January 1970).
</p>
<p>
If no message is available, and the timeout has already expired by the time of
the call, <code>mq_timedreceive()</code> returns immediately.
</p>
<p>
<b>Input Parameters:</b>
</p>
<ul>
<li><code>mqdes</code>. Message Queue Descriptor.</li>
<li><code>msg</code>. Buffer to receive the message.</li>
<li><code>msglen</code>. Size of the buffer in bytes.</li>
<li><code>prio</code>. If not NULL, the location to store message priority.
<li><code>abstime</code>. The absolute time to wait until a timeout is declared.
</ul>
<p>
<b>Returned Values:</b>.
One success, the length of the selected message in bytes is returned.
On failure, -1 (<code>ERROR</code>) is returned and the <code>errno</code> is set appropriately:
</p>
<ul>
<li>
<code>EAGAIN</code>:
The queue was empty and the <code>O_NONBLOCK</code> flag was set for the message queue description referred to by <code>mqdes</code>.
</li>
<li>
<code>EPERM</code>:
Message queue opened not opened for reading.
</li>
<li>
<code>EMSGSIZE</code>:
<code>msglen</code> was less than the <code>maxmsgsize</code> attribute of the message queue.
</li>
<li>
<code>EINTR</code>:
The call was interrupted by a signal handler.
</li>
<li>
<code>EINVAL</code>:
Invalid <code>msg</code> or <code>mqdes</code> or <code>abstime</code>
</li>
<li>
<code>ETIMEDOUT</code>:
The call timed out before a message could be transferred.
</li>
</ul>
<p>
<b>Assumptions/Limitations:</b>
</p>
<p>
<b>POSIX Compatibility:</b>
Comparable to the POSIX interface of the same name.
</p>
<h3><a name="mqnotify">2.4.7 mq_notify</a></h3>
int mq_notify(mqd_t mqdes, const struct sigevent *notification);
</pre>
<p>
<b>Description:</b> If the "notification" input parameter
is not NULL, this function connects the task with the message queue such
that the specified signal will be sent to the task whenever the message
changes from empty to non-empty. One notification can be attached
to a message queue.
If "notification" is NULL, the attached notification
is detached (if it was held by the calling task) and the queue
is available to attach another notification.
When the notification is sent to the registered task, its registration
will be removed. The message queue will then be available for
registration.
<p>
<b>Input Parameters:</b>
<ul>
<li><I>mqdes</I>. Message queue descriptor
<li><I>notification</I>. Real-time signal structure containing:
<ul>
<li><I>sigev_notify</I>. Should be osSIGEV_SIGNAL (but actually
<li><I>sigev_signo</I>. The signo to use for the notification
<li><I>sigev_value</I>. Value associated with the signal
</ul>
</ul>
<p>
<b>Returned Values:</b> None.
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX interface
of the same name.
Differences from the full POSIX implementation include:
<ul>
<li>The notification signal will be sent to the registered task even if
another task is waiting for the message queue to become non-empty. This is
inconsistent with the POSIX specification which states, "If a process
has registered for notification of message arrival at a message queue and
some process is blocked in <I>mq_receive</I> waiting to receive a message
when a message arrives at the queue, the arriving message shall satisfy the
appropriate <I>mq_receive()</I> ... The resulting behavior is as if the
message queue remains empty, and no notification shall be sent."
<H3><a name="mqsetattr">2.4.8 mq_setattr</a></H3>
#include <mqueue.h>
int mq_setattr( mqd_t mqdes, const struct mq_attr *mqStat,
struct mq_attr *oldMqStat);
<p>
<b>Description:</b> This function sets the attributes associated
with the specified message queue "mqdes." Only the "O_NONBLOCK"
bit of the "mq_flags" can be changed.
If "oldMqStat" is non-null, mq_setattr() will store
the previous message queue attributes at that location (just as
would have been returned by mq_getattr()).
<p>
<b>Input Parameters:</b>
<ul>
<li><I>mqdes</I>. Message queue descriptor
<li><I>mqStat</I>. New attributes
<li><I>oldMqState</I>. Old attributes
</ul>
<p>
<b>Returned Values:</b>
<ul>
<li>0 (OK) if attributes are set successfully, otherwise -1
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
<H3><a name="mqgetattr">2.4.9 mq_getattr</a></H3>
#include <mqueue.h>
int mq_getattr( mqd_t mqdes, struct mq_attr *mqStat);
<p>
<b>Description:</b> This functions gets status information and
<p>
<b>Input Parameters:</b>
<ul>
<li><I>mqdes</I>. Message queue descriptor
<li><I>mqStat</I>. Buffer in which to return attributes. The returned
<ul>
<li><I>mq_maxmsg</I>. Max number of messages in queue.
<li><I>mq_msgsize</I>. Max message size.
<li><I>mq_flags</I>. Queue flags.
<li><I>mq_curmsgs</I>. Number of messages currently in queue.
</ul>
</ul>
<p>
<b>Returned Values:</b>
<ul>
<li>0 (OK) if attributes provided, -1 (ERROR) otherwise.
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
<H2>2.5 <A NAME="Semaphores">Counting Semaphore Interfaces</a></H2>
<p>
<b>Semaphores</b>. Semaphores are the basis for
synchronization and mutual exclusion in NuttX. NuttX supports
POSIX semaphores.
</p>
<p>
Semaphores are the preferred mechanism for gaining exclusive access to a
resource. sched_lock() and sched_unlock() can also be used for this purpose.
However, sched_lock() and sched_unlock() have other undesirable side-affects
in the operation of the system: sched_lock() also prevents higher-priority
tasks from running that do not depend upon the semaphore-managed resource
and, as a result, can adversely affect system response times.
</p>
<p>
<b>Priority Inversion</b>. Proper use of semaphores avoids the issues of
sched_lock(). However, consider the following example:
<OL>
<li>Some low-priority task, <I>Task C</I>, acquires a semphore in order to
<li><I>Task C</I> is suspended to allow some high-priority task,</li>
<li><I>Task A</I> attempts to acquire the semaphore held by <I>Task C</I> and
gets blocked until <I>Task C</I> relinquishes the semaphore.</li>
<li><I>Task C</I> is allowed to execute again, but gets suspended by some
medium-priority <I>Task B</I>.</li>
</OL>
<p>
At this point, the high-priority <I>Task A</I> cannot execute until
<I>Task B</I> (and possibly other medium-priority tasks) completes and until
<I>Task C</I> relinquishes the semaphore. In effect, the high-priority task,
<I>Task A</I> behaves as though it were lower in priority than the
low-priority task, <I>Task C</I>! This phenomenon is called <I>priority
inversion</I>.
</p>
<p>
Some operating systems avoid priority inversion by <I>automatically</I>
increasing the priority of the low-priority <I>Task C</I> (the operable
buzz-word for this behavior is <I>priority inheritance</I>). NuttX does not
support this behavior. As a consequence, it is left to the designer to
provide implementations that will not suffer from priority inversion.
The designer may, as examples:
</p>
<ul>
<li>Implement all tasks that need the semphore-managed resources at the
<li>Boost the priority of the low-priority task before the semaphore is
<p>
POSIX semaphore interfaces:
</p>
<ul>
<li><a href="#seminit">2.5.1 sem_init</a></li>
<li><a href="#semdestroy">2.5.2 sem_destroy</a></li>
<li><a href="#semopen">2.5.3 sem_open</a></li>
<li><a href="#semclose">2.5.4 sem_close</a></li>
<li><a href="#semunlink">2.5.5 sem_unlink</a></li>
<li><a href="#semwait">2.5.6 sem_wait</a></li>
<li><a href="#semtrywait">2.5.7 sem_trywait</a></li>
<li><a href="#sempost">2.5.8 sem_post</a></li>
<li><a href="#semgetvalue">2.5.9 sem_getvalue</a></li>
</ul>
<H3><a name="seminit">2.5.1 sem_init</a></H3>
#include <semaphore.h>
int sem_init ( sem_t *sem, int pshared, unsigned int value );
<p>
<b>Description:</b> This function initializes the UN-NAMED semaphore
sem. Following a successful call to sem_init(), the semaphore
may be used in subsequent calls to sem_wait(), sem_post(), and
sem_trywait(). The semaphore remains usable until it is destroyed.
Only <I>sem</I> itself may be used for performing synchronization. The
result of referring to copies of <I>sem</I> in calls to <I>sem_wait()</I>,
<I>sem_trywait()</I>, <I>sem_post()</I>, and <I>sem_destroy()</I>, is
not defined.
<p>
<b>Input Parameters:</b>
<ul>
<li><I>sem</I>. Semaphore to be initialized
<li><I>pshared</I>. Process sharing (not used)
<li><I>value</I>. Semaphore initialization value
</ul>
<p>
<b>Returned Values:</b>
<ul>
<li>0 (OK), or -1 (ERROR) if unsuccessful.
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
interface of the same name.
Differences from the full POSIX implementation include:
#include <semaphore.h>
int sem_destroy ( sem_t *sem );
<p>
<b>Description:</b> This function is used to destroy the un-named semaphore
indicated by <I>sem</I>. Only a semaphore that was created using
<I>sem_init()</I> may be destroyed using <I>sem_destroy()</I>. The effect
of calling <I>sem_destroy()</I> with a named semaphore is undefined. The
effect of subsequent use of the semaphore <I>sem</I> is undefined until
<I>sem</I> is re-initialized by another call to <I>sem_init()</I>.
The effect of destroying a semaphore upon which other tasks are currently
blocked is undefined.
<p>
<b>Input Parameters:</b>
<ul>
<li><I>sem</I>. Semaphore to be destroyed.
</ul>
<p>
<b>Returned Values:</b>
<ul>
<li>0 (OK), or -1 (ERROR) if unsuccessful.
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
#include <semaphore.h>
sem_t *sem_open ( const char *name, int oflag, ...);
<p>
<b>Description:</b> This function establishes a connection between
named semaphores and a task. Following a call to sem_open() with
the semaphore name, the task may reference the semaphore associated
with name using the address returned by this call. The semaphore
may be used in subsequent calls to sem_wait(), sem_trywait(),
and sem_post(). The semaphore remains usable until the semaphore
is closed by a successful call to sem_close().
If a task makes multiple calls to sem_open() with the same name,
then the same semaphore address is returned (provided there have
been no calls to sem_unlink()).
<p>
<b>Input Parameters:</b>
<ul>
<li><I>name</I>. Semaphore name
<li><I>oflag</I>. Semaphore creation options. This may one of
<ul>
<li><I>oflag</I> = 0: Connect to the semaphore only if it already
NOTE: When the O_CREAT flag is specified, POSIX requires that a third
and fourth parameter be supplied:
This parameter is required but not used in the present
implementation.
<li><I>value</I>. The value parameter is type unsigned int. The semaphore
is created with an initial value of <I>value</I>. Valid initial values for
semaphores must be less than or equal to <I>SEM_VALUE_MAX</I> (defined in
<CODE>include/limits.h</CODE>).
</ul>
</ul>
<p>
<b>Returned Values:</b>
<ul>
<li>A pointer to sem_t or -1 (ERROR) if unsuccessful.
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
interface of the same name.
Differences from the full POSIX implementation include:
<ul>
<li>Treatment of links/connections is highly simplified. It is
<p>
<b>Description:</b> This function is called to indicate that the
calling task is finished with the specified named semaphore, sem.
The sem_close() deallocates any system resources allocated by
the system for this named semaphore.
If the semaphore has not been removed with a call to sem_unlink(),
then sem_close() has no effect on the named semaphore. However,
when the named semaphore has been fully unlinked, the semaphore
will vanish when the last task closes it.
Care must be taken to avoid risking the deletion of a semaphore
that another calling task has already locked.
<p>
<b>Input Parameters:</b>
<ul>
<li><I>sem</I>. Semaphore descriptor
</ul>
<p>
<b>Returned Values:</b>
<ul>
<li>0 (OK), or -1 (ERROR) if unsuccessful.
</ul>
<p>
<b>Assumptions/Limitations:</b>
<ul>
<li>Care must be taken to avoid deletion of a semaphore that another task
<li>sem_close() must not be called with an un-named semaphore.
</ul>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
#include <semaphore.h>
int sem_unlink ( const char *name );
<p>
<b>Description:</b> This function will remove the semaphore named by the
input name parameter. If one or more tasks have the semaphore named by
name oepn when sem_unlink() is called, destruction of the semaphore will
be postponed until all references have been destroyed by calls to
sem_close().
<p>
<b>Input Parameters:</b>
<ul>
<li><I>name</I>. Semaphore name
</ul>
<p>
<b>Returned Values:</b>
<ul>
<li>0 (OK), or -1 (ERROR) if unsuccessful.
</ul>
<p>
<b>Assumptions/Limitations:</b>
<ul>
<li>Care must be taken to avoid deletion of a semaphore that another task
<li>sem_unlink() must not be called with an un-named semaphore.
</ul>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
interface of the same name.
Differences from the full POSIX implementation include:
<ul>
<li>Treatment of links/connections is highly simplified. It is
<li>Calls to sem_open() to re-create or re-connect to the semaphore may
refer to the same semaphore; POSIX specifies that a new semaphore with the
same name should be created after sem_unlink() is called.
<p>
<b>Description:</b> This function attempts to lock the semaphore
referenced by sem. If the semaphore as already locked by another
task, the calling task will not return until it either successfully acquires
the lock or the call is interrupted by a signal.
<p>
<b>Input Parameters:</b>
<ul>
<li><I>sem</I>. Semaphore descriptor.
</ul>
<p>
<b>Returned Values:</b>
<ul>
<li>0 (OK), or -1 (ERROR) is unsuccessful
</ul>
<p>
If <I>sem_wait</I> returns -1 (ERROR) then the cause of the failure
will be indicated by the thread-specific <I>errno</I> value (a pointer
to this value can be obtained using <I>get_errno_ptr()</I>). The following
lists the possible values for <I>errno</I>:
<p>
<ul>
<li><I>EINVAL</I>: Indicates that the <I>sem</I> input parameter is
<li><I>EINTR</I>: Indicates that the wait was interrupt by a signal
received by this task. In this case, the semaphore has not be acquired.
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
#include <semaphore.h>
int sem_trywait ( sem_t *sem );
<p>
<b>Description:</b> This function locks the specified semaphore
only if the semaphore is currently not locked. In any event, the call
returns without blocking.
<p>
<b>Input Parameters:</b>
<ul>
<li><I>sem</I>. The semaphore descriptor
</ul>
<p>
<b>Returned Values:</b>
<ul>
<li>0 (OK) or -1 (ERROR) if unsuccessful
</ul>
If <I>sem_wait</I> returns -1 (ERROR) then the cause of the failure
will be indicated by the thread-specific <I>errno</I> value (a pointer
to this value can be obtained using <I>get_errno_ptr()</I>). The following
lists the possible values for <I>errno</I>:
<p>
<ul>
<li><I>EINVAL</I>: Indicates that the <I>sem</I> input parameter is
<li><I>EAGAIN</I>: Indicates that the semaphore was not acquired.
</ul>
<p>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
<p>
<b>Description:</b> When a task has finished with a semaphore,
it will call sem_post(). This function unlocks the semaphore referenced
by <I>sem</I> by performing the semaphore unlock operation.
If the semaphore value resulting from this operation is positive, then
no tasks were blocked waiting for the semaphore to become unlocked;
The semaphore value is simply incremented.
If the value of the semaphore resulting from this operation is zero, then
on of the tasks blocked waiting for the semaphore will be allowed to
return successfully from its call to <I>sem_wait()</I>.
<p>
<b>NOTE</b>: <I>sem_post()</I> may be called from an interrupt handler.
<p>
<b>Input Parameters:</b>
<ul>
<li><I>sem</I>. Semaphore descriptor
</ul>
<p>
<b>Returned Values:</b>
<ul>
<li>0 (OK) or -1 (ERROR) if unsuccessful.
</ul>
<p>
<b>Assumptions/Limitations:</b> This function cannot be called
from an interrupt handler. It assumes the currently executing
task is the one that is performing the unlock.
#include <semaphore.h>
int sem_getvalue ( sem_t *sem, int *sval );
<p>
<b>Description:</b> This function updates the location referenced
by sval argument to have the value of the semaphore referenced
by sem without effecting the state of the semaphore. The updated
value represents the actual semaphore value that occurred at some
unspecified time during the call, but may not reflect the actual
value of the semaphore when it is returned to the calling task.
If sem is locked, the value return by sem_getvalue() will either
be zero or a negative number whose absolute value represents the
number of tasks waiting for the semaphore.
<p>
<b>Input Parameters:</b>
<ul>
<li><I>sem</I>. Semaphore descriptor
<li><I>sval</I>. Buffer by which the value is returned
</ul>
<p>
<b>Returned Values:</b>
<ul>
<li>0 (OK) or -1 (ERROR) if unsuccessful.
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
NuttX provides a general watchdog timer facility.
This facility allows the NuttX user to specify a watchdog timer function
that will run after a specified delay.
The watchdog timer function will run in the context of the timer interrupt handler.
Because of this, a limited number of NuttX interfaces are available to he watchdog timer function.
However, the watchdog timer function may use <code>mq_send()</code>, <code>sigqueue()</code>,
or <code>kill()</code> to communicate with NuttX tasks.
</p>
<ul>
<li><a href="#wdcreate">2.6.1 wd_create</a></li>
<li><a href="#wddelete">2.6.2 wd_delete</a></li>
<li><a href="#wdstart">2.6.3 wd_start</a></li>
<li><a href="#wdcancel">2.6.4 wd_cancel</a></li>
<li><a href="#wdgettime">2.6.5 wd_gettime</a></li>
<p>
<b>Description:</b> The wd_create function will create a watchdog
<p>
<b>Input Parameters:</b> None.
<p>
<b>Returned Values:</b>
<ul>
<li>Pointer to watchdog that may be used as a handle in subsequent
NuttX calls (i.e., the watchdog ID), or NULL if insufficient resources
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> This is a NON-POSIX interface.
<ul>
<li>The number of available watchdogs is fixed (configured at
<p>
<b>Description:</b> The wd_delete function will deallocate a
watchdog. The watchdog will be removed from the timer queue if
has been started.
<p>
<b>Input Parameters:</b>
<ul>
<li><I>wdog</I>. The watchdog ID to delete. This is actually a
<p>
<b>Returned Values:</b>
<ul>
<li>OK or ERROR
</ul>
<p>
<b>Assumptions/Limitations:</b> It is the responsibility of the
caller to assure that the watchdog is inactive before deleting
it.
<p>
<b> POSIX Compatibility:</b> This is a NON-POSIX interface.
<ul>
<li>Does not make any checks to see if the watchdog is being used
Loading
Loading full blame...