Home > Mutual Exclusion, Projects, RTOS, SKC++ > SKC++: Mutual Exclusion

SKC++: Mutual Exclusion

Wednesday, December 2, 2009 Leave a comment Go to comments

Just a short article today as SKC++’s mutual exclusion facilities follow a familiar pattern:


It seemed like a good idea to provide another abstract interface as there can, in principle, be several kinds of mutex. The one I chose as “standard” for SKC++ is the priority-inheritance mutex. Fortunately, I don’t have to explain the ins and outs of this or, indeed, of mutual exclusion in general, as an esteemed business associate – Niall Cooling of Feabhas – made a good job of this some time ago in a three-article expostion in his blog, the last part of which can be found here.

I’ve been working on what will become the user documentation for SKC++ and as part of that I’ve adopted a colour code in my UML diagrams. Blue indicates those classes which a user needs to be involved with. The default beige (none visible in this diagram) is broadly for classes which are internal to SKC++ but contain information, such as public and protected method specifications, which is important or interesting for a user. Grey is for internal SKC++ classes which are of only academic interest (if that!) to anyone but me.

Continuing with the blue, you will have noticed another class called ScopeLock. I thought I’d invented this name myself but Google taught me otherwise. The actual concept is as unoriginal as that of the mutex. A ScopeLock object associates itself with and locks a specified mutex on construction and unlocks the mutex on destruction. It is used like this:

Mutex myMutex;
    ScopeLock lock(myMutex);
    // Access the shared data...
// The mutex  was unlocked when the code left the block.

Using ScopeLock is usually to be preferred over ad hoc locking and unlocking of the mutex because the former is less error-prone.

Although I’ve coloured it grey, SK_Mutex is worth a mention because its modus operandi will crop up again when I consider interrupts, which I will be doing soon. It is sometimes necessary, deep within the kernel, to perform mutual exclusion briefly using a faster, more fundamental but more brutal technique than an ordinary mutex. In fact, when playing with the task queue associated with a mutex, such a technique must be employed. One way to do this is to disable interrupts but a slightly kinder way, which is adequate most of the time, is to prevent task pre-emption by temporarily blocking the scheduler. This is the way SK_Mutex works.

By using message-passing and in other ways, it is possible to avoid the need for a mutex most of the time. However, on the few occasions a mutex is needed it really is needed, and no RTOS would be complete without one.

Categories: Mutual Exclusion, Projects, RTOS, SKC++ Tags:
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: