At the heart of a real time operating system (RTOS) is the kernel, which is comprised of the task scheduler and a bunch of services that are available for application programs. Control of the scheduler and access to these services is by means of the kernel’s application program interface (API). APIs differ from one RTOS to another (although there are some standards, like POSIX), but there are some characteristics which are common to many. One of those similarities is the concept of blocking and non-blocking calls.
The idea is fairly straightforward. A program may make an API call to request a specific resource or service. Such a call may normally return with the required result and/or a pointer to requested resources. There may also be the possibility for an error result. But, what if the call is valid, but the resource or service cannot be provided at this time? There are two ways to make such a call, which differ in their response to this unavailability: a blocking call results in the task being suspended (put to sleep) and the task will be woken when the request can be fulfilled; a non-blocking call results in an error code being returned and the task has the option of trying the call again later.
