Sirius RTOS provides a comprehensive set of system objects representing various system resources. These objects facilitate task synchronization, critical section management, interprocess data exchange, and event notification. Each object is identified by a unique handle assigned by the kernel. Additionally, objects may optionally be assigned names to assist in identification across different tasks. A complete list and detailed descriptions of all available objects can be found in the system objects section.

All system objects, with the exception of tasks, may be assigned an optional name during creation. Naming allows a task to retrieve an object's handle when the system-assigned handle is unknown. While all subsequent operations require a handle, the osOpen* functions (where * denotes the object type, such as Mutex) allow a task to open an object by name to obtain its handle. Detailed information on object opening procedures is provided in the following section.

Object names are case-insensitive strings, with a maximum length defined by the OS_SYS_OBJECT_MAX_NAME_LEN constant. If this value is set to 0, names are treated as integer values of the INDEX type. Object names must always be passed to system functions using the SYSNAME abstraction. Depending on the system configuration, this type automatically maps to either PSTR or INDEX.

When an object is created, the kernel returns a unique handle used to identify that specific instance during system calls. When an object is no longer required, its handle must be closed to facilitate deletion. An object is physically deleted only when all tasks that have opened the object have subsequently closed it using the osCloseHandle function.

Objects created by one task may be utilized by others. If an object is deleted while an operation is still in progress, unpredictable behavior or system failure may occur. To prevent this, every task accessing a shared object should first invoke an osOpen* or osOpenByHandle function to increment the object's reference count. The object will remain resident in memory until the last remaining handle is closed. Note that objects created before kernel initialization or within an ISR (Interrupt Service Routine) are persistent and will never be deleted by the system.

If name-based lookup functions are not utilized in the application, the system will ignore object names and omit the name-management logic. This optimization reduces the final footprint of the executable code.

In applications where objects are never deleted, the OS_ALLOW_OBJECT_DELETION constant should be set to 0. In this configuration, the osCloseHandle function is disabled, and osOpen* functions simply return the handle without performing reference tracking. This significantly reduces system resource consumption and code size.

The osOpenByHandle function is used to open an object when the handle is already known, specifically to protect the object from premature deletion by another task.