Events are synchronization primitives that exist in one of two states-signaled or non-signaled-and are used to notify tasks of specific system activities or conditions.

The osCreateEvent function is used to create an event object. Events may be initialized before the system starts, within an interrupt service routine, or by a task. During creation, an optional name may be assigned to the event, allowing other tasks to obtain a handle to it via the osOpenEvent function. Both creation and opening return a system-assigned handle used to uniquely identify the object. All subsequent operations on the event require this handle. When an event is no longer needed, it should be closed using osCloseHandle. An event object is deleted only after all tasks that opened a handle to it have closed them. Further details are available in the system objects management section.

If event objects are not required in the application, the OS_USE_EVENT constant can be set to 0 to reduce the final binary size.

The state of an event can be modified at any time using the osSetEvent and osResetEvent functions, which transition the object to the signaled and non-signaled states, respectively. The initial state of the event is defined during its creation.

Whether an event is manual-reset or auto-reset is also determined at creation. For a manual-reset event, the state remains signaled until it is explicitly cleared via osResetEvent. In contrast, an auto-reset event automatically transitions to the non-signaled state as soon as a single waiting task successfully completes its wait operation. In this case, only one of the waiting tasks is resumed. An auto-reset event can effectively serve as a simple binary semaphore.

When an event becomes signaled while multiple tasks are waiting, the task with the highest priority is resumed first. If all waiting tasks have a lower priority than the task that modified the event state, they will be scheduled to run once they are ready. If a task with a higher priority subsequently begins waiting for the signaled event, it will acquire the event immediately, as it takes precedence over the existing waiting tasks.

Specifically for auto-reset events, if a task attempts to acquire a signaled event and has a priority equal to or lower than other waiting tasks, it is appended to the end of the pending queue. If there are no other tasks waiting, the task completes its wait operation immediately with success and the event state is automatically reset to non-signaled.