Sign In
Forgot Password?
Sign In | | Create Account

Reentrant write-only ports

Colin Walls

Colin Walls

Posted Feb 11, 2013

Recently I posted about the challenges of using a write only port. Then I followed that up with another posting that illustrated the use of C++ to encapsulate the necessary coding nastiness. Hopefully, these two postings conveyed the general ideas – defining the problem and outlining a solution.

However, one aspect of the solution was not addressed: the proposed code was not reentrant …

Reentrancy is a potential issue in any multi-threaded system. It needs to be considered if you are using an RTOS or have mainline code and interrupt service routines. In these cases, a sequence of instructions may be interrupted at any time and another thread be given control of the CPU. At some later point the instruction sequence will be resumed. This is fine, unless it is essential that the sequence be completed in one go, without interruption. Such a sequence is often referred to as a “critical section” and measures need to be taken to avoid the interruption.

In the write only port handling code that I have presented so far, the critical section is the two lines of code that update the shadow copy and the writing to the port, for example:

shadow &= val;
*address = shadow;

The problem is that, if an interrupt occurred after the shadow was updated and the new thread utilizes the port, the correct value may never be written. In some cases that might not matter, but, in others, it is essential that every update is written to the port.

The solution is conceptually quite straightforward: the port needs to be “locked” before this pair of statements and “unlocked” afterwards. The code would simply look like this:

shadow &= val;
*address = shadow;

These member functions – lock() and unlock() – could be implemented in a variety of way. The brute force approach would be to simply disable and re-enable interrupts. With an RTOS, using a semaphore or a mutex would be a better approach.

In the spirit of object oriented programming practice, it would be sensible to add these functions to the write_only_port class, but make them virtual. This means that, where reentrancy is not an issue, the class may be used as it stands. If a reentrant version is required, it may be derived from this base class and the lock() and unlock() instantiated appropriately.

device drivers, drivers, RTOS

More Blog Posts

About Colin Walls Follow on Twitter

Colin WallsI have over thirty 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: Visit The Colin Walls Blog

More Posts by Colin Walls


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)


Online Chat