The three basic principles which guided me in the design of SKC++ were that it should be:

- Easy to learn
- Easy to use
- Difficult to misuse

My own experience and that of other engineers that I have asked about it is that we like to reserve our time and creativity for the challenge facing us. We don’t want to waste too much time learning how a tool works, or agonising about its options; that should not be part of the challenge. I regard SKC++ primarily as a tool for Application Engineers.

Richness does have its place and there is an argument that you appeal to a greater market if you provide all the traditional, “expected” features as well as any new ones. However, my mission these days is not to sell millions of copies of SKC++ (though more than one or two would be nice), but to distil decades of experience into what I do and deliver only the best bits, thereby making my small contribution to improving embedded software quality. (For the historical enlightenment of those starting out in the profession, I might occasionally blog about the less good bits, but that’s another subject.)

Of course the problem with Occam’s Razor is that you can slice off too much. But to counter that by adding redundant features “just in case” is cowardice. There’s a thin line somewhere in between and that’s why I threw the Semaphore argument open.

Here are some other arguments for the lean approach:

- Quicker to market (though I still haven’t got there)
- Less to go wrong
- Easier to add features, on demand, than to take them away after publication

Who knows, I might make more money adding redundant features for traditionalists (or others stuck in their ways by choice or by circumstance) than I make from the basic product!

Getting a product accepted is about the user experience. That applies as much to an RTOS as to a toy like an iPad. Have you ever stood behind someone while they use a program you are a hot shot at, say Excel, and suddenly notice them doing something in quite a different way to how you would? That’s richness.

The other argument in favour of richness is that it gives uses more opportunities to perhaps use the product in ways you, the maker, didn’t anticipate. Which of course in an RTOS may not always be a Good Thing

David Stonier-Gibson http://splatco.com

- Too many system calls
- Written in C

My sentiments, exactly. I mentioned the semaphore only because I imagined many people would expect to see such a thing in any RTOS. I appear to have been wrong about that, happily!

However, the inner heart of the kernel (downgraded to C), plus a semaphore (easy to code), plus some nasty POSIX, probably, would do the job

I’m not sure how useful it is to look at items like semaphores, mutexs, etc. in isolation. The primary question for the designer is ‘what is the software trying to achieve?’ (e.g., passing information between concurrent units, synchronization of operations or protection of operations/data). The next question: what is the ‘best’ way of doing this? Final question: what are the pros/cons of the chosen technique(s)?

Semaphores, mutexs, protected objects etc. are enabling mechanisms; their qualities should be assessed from this point of view.

Since I grew up with Ada however, I should make a case for rendezvous. There are certainly cases where the fact that you can exchange data between tasks __in both directions__ is very useful, and can avoid some of the anti-patterns you have mentioned – like loops of events going between tasks (A triggers B triggers C triggers A, etc.).

But as always, you are right – these situations normally occur because the architect hasn’t thought about it enough.

In SKC++ the efficiency of the semaphore for signalling (actually slightly better) is obtained by using a bare event flag, without the overhead of an accompanying message where none is needed. However, I’ve stuck my neck out by providing no autonomous object which can stand in for a semaphore (say, for a rendezvous); both event groups and message queues are tied to and are effectively part of the particular tasks which wait at them.

1. That mutexes are superior to semaphores for mutual exclusion in a system with deadlines. Only the mutex can prevent a priority inversion.

2. That rendezvous is a bad idea. If you are having that kind of coupling between two tasks, there is probably a more elegant solution to your overall software architecture. It probably involves the passing of event ids via message queues.

In most respects, a message queue and a semaphore are identical constructs. The message is always the same (whatever is agreed by sender and receiver) in the case of a semaphore. This means the semaphore implementation is a more efficient subcase of the message queue. If you don’t care about the efficiency of the empty-message subcase of message queues, you can use a message queue for anything you would use a semaphore for (even rendezvous).

I’ve written a few things on mutexes vs. semaphores in my blog at http://www.embeddedgurus.net/barr-code. In addition, I’m the host of a webinar on that subject at http://www.techonline.com.