I’ve been looking over my SKC++ postings so far and have come to the conclusion that it’s time for a review. Also, before launching into the details of the kernel’s message-passing techniques, I need to show why message-passing is needed in the first place. I’ll start by presenting some thoughts on the tasking model. Read more…
Just possibly, you may have been wondering why Task::wait does not include a timeout parameter. The answer is that it does not need to because a timeout is itself an event, so this can be waited for along with whatever event might be timed out. SKC++ has general-purpose timers which can be used not only for timing out other events but in their own right for other purposes. Here is a picture:- Read more…
Systems running a pre-emptive kernel are essentially event-driven.
Primary events are things which happen outside the software system, in the real world. These are usually communicated to the software via Interrupt Service Routines (ISRs) which are pre-emptively “called” by the hardware interrupt mechanism of the processor. Our kernel becomes aware of the event if and only if the ISR signals its occurrence, in some way, to a task. Read more…
Today’s post discusses the basic structure and characteristics of an SKC++ task. Here is a picture of the class, together with a skeletal but updated version of the Pooled class, from which Task inherits: Read more…
Having spent almost my entire career in embedded and real-time software, I have become familiar with the term “task” to describe what might be called a “unit of concurrency” in a software system. Many people now use the term “thread” instead. Is there any difference? Yes and No. Here’s my take on it: Read more…