Sign In
Forgot Password?
Sign In | | Create Account

Blocking and non-blocking APIs

Colin Walls

Colin Walls

Posted Nov 30, 2009
0 Comments

I recently received an email from a regular reader of this blog. I am always very happy to receive feedback, comments and suggestions. In this case, it was a suggestion for a topic to address, which was particularly welcome. The writer wanted me to talk about blocking and non-blocking APIs …

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, which 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]; the task will be woken when the request can be fulfilled. A non-blocking call results in an error code being returned; the task has the option of trying the call again later.

What if several tasks are blocked pending the availability of a resource, which then becomes available? Which task is woken up to have its request satisfied? This depends upon the specific RTOS. Typically tasks are either woken in priority order [i.e. a higher priority task will be woken first] or they are woken in the order in which they suspended [“first in, first out”- FIFO]. This may be a kernel configuration choice or may be selectable on a per-object basis.
The choice of using a blocking or non-blocking call is generally up to the applications programmer. Using a non-blocking call is simple to understand – typically the task would put itself to sleep for a while then try again. A blocking call is simpler to code and reduces the use of system resources, as the task remains suspended and not in contention for CPU time until the resource is available.

We can look at a real example. The Nucleus RTOS supports semaphores, which may be created with a call like this:

	STATUS NU_Create_Semaphore(NU_SEMAPHORE *semaphore, CHAR *name,
UNSIGNED initial_count, OPTION suspend_type);

The last parameter determines how blocked tasks are woken up; the options are priority [NU_PRIORITY] or FIFO [NU_FIFO] order.

Obtaining a semaphore requires a call like this:

	STATUS NU_Obtain_Semaphore(NU_SEMAPHORE *semaphore,
UNSIGNED suspend);

The blocking/non-blocking behavior is determined by the last parameter. This may be set to NU_SUSPEND [indefinite blocking], NU_NO_SUSPEND [non-blocking], or to a timeout value, which specifies how long [in clock ticks] the task will be suspended for pending the availability of the semaphore.

The Nucleus API offers the same flexibility for all relevant API calls.

Nucleus Kernel, RTOS, API, Nucleus

More Blog Posts

About Colin Walls Follow on Twitter

Colin WallsI have over twenty-five years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, I am a member of the marketing team of the Mentor Graphics Embedded Systems Division, and am based in the UK. Away from work, I have a wide range of interests including photography and trying to point my two daughters in the right direction in life. Learn more about Colin, including his go-to karaoke song and the best parts of being British: http://go.mentor.com/3_acv Visit The Colin Walls Blog

More Posts by Colin Walls

Comments

No one has commented yet on this post. Be the first to comment below.

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)

Archives

 
Online Chat