My code, which you can download if you wish, can’t detect or prevent the coding errors which cause memory leaks but definitely can get rid of the fragmentation problem inherent in all heap (variable block size) allocation systems. No tool can help you with this! IT programmers can generally ignore fragmentation and get away with it; embedded programmers most certainly cannot.

Actually, I lied. The Managed class and its associated smart Ptr class are now part of my software bundle and proper use of these can help greatly to prevent memory leaks.

Thank you for your interest.

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!

Thanks for your comment about DO-178B. I’ve moved it to the Software Download page (link above), and have replied to it there.

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

To those people:
You are still registered, of course, and I have changed nothing in your user accounts!

- 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.

Can’t overload class names (template and non-template) like I did with MessgePtr in the diagram. That works only for functions!

Update…

I corrected the article (and updated this comment) on 09 November 2009. The rules of blogging are breakable; the rules of C++ are not!

As you say, an intermediate task provides a solution, when needed. However, I’m thinking hard just now about synchronisation approaches for SKC++ and I’m sure there’s a more efficient solution lurking in there, somewhere.

But if you only allow direct message-passing, how will you implement a task-pool concept (dare I say “pattern”)? That’s where I can can have X (identical) tasks all waiting on one message queue. I guess I would need an additional mediator/coordinator task?

The answer is embodied in my more recent article “SKC++: Pause for Thought”.

(No, I still haven’t dealt with mutual exclusion but it was at least mentioned in that article.)

As you are doubtless aware, I have agreed with you elsewhere (on a LinkedIn discussion) that co-operative multitasking is often to be preferred in systems where pre-emption is definitely not needed. A co-operative system, although its partitioning suggests concurrency, is actually sequential in operation. Therefore it is much less finicky about programming practices, making it much less error-prone. With my teaching hat on, though, I always encourage the type of programming which is safe in a pre-emptive environment. That way, people’s skills are more transferable.

Perhaps I can deal with your final point by saying that it will be possible to turn pre-emption off in SKC++!

One insight I find very interesting and valuable, though, is your observation about different kinds of programmers, System and Application. I myself pontificate in the shower these days about preemptive vs cooperative O/Ss and the target audience. I believe for an iPhone preemptive is a necessary evil, because anyone can squirt a new app into it at any time. For small, static (i.e. the program is frozen at Flash time) highly deterministic embedded controls, I vote cooperative (this is my domain).

So, I think maybe you should add one more bullet point to your September 9 post “Simplifying RTOS”

* Failing to properly define the target audience.

IMHO anything that tries to be all things to all people winds up a mess.

David Stonier-Gibson http://splatco.com

I have another, rather different idea for talking to multiple tasks in a structured way, but it will be a little while before it reaches this blog. I’ll let you know when!

I think task is more descriptive of the idea that this is something that does something, on its own cognizance, to contribute to the overall objectives of the system.

I have recently been developing the concept of Acters. An Acter is a unit of program roughly equivalent to an object, but it contains one or more tasks (usually FSMs), some shared data an several methods to interface to the outside world. More at http://www.splatco.com/acter_model_1.htm