RTOS system design--how many tasks?

On Fri, 08 Jun 2007 05:47:24 -0700, james.ro123@yahoo.com wrote:

>Hi,
>
>We're designing a new system using an RTOS.  Everyone on the team has
>worked with an RTOS before, but none of us has ever designed a
>system.  One thing I'm concerned with is we may end up with too many
>tasks.  

I have used this rule of thumb (sic) for decades: Keep the number of
tasks below 11 so you can count the tasks with your fingers. In
exceptional cases up to 20 tasks could be used, but my colleagues
might not like if I take my socks off and use also my toes to count
the tasks :-).

>I reviewed my papers/magazines and searched the web for half a
>day and didn't get much info.  So, for those of you who've been
>through this before, I have a couple of basic questions:
>
>1)  What are the disadvantages of a lot of tasks (besides inefficient
>stack usage)?  I'm concerned it may exacerbate deadlock, make it
>harder to debug, create synchronization issues, etc.

As long as you have a clear system, in which task owns a specific data
set (i.e. is allowed to modify it) and use as much atomic data types
as possible, the need for task synchronisation primitives is reduced
and also the risk for priority inversions and other deadlock
situations is minimised.

>2)  How do you decide when to create a task?  We decided to create a
>"task creation criteria" to aid us.  Right now it has the following:
>a) any defined events in the system (button presses, etc.) should be
>in a task, b) anything that is going to take a while to complete (i.e.
>background processing) should be in a task and c) could placing stuff
>in a task aid in synchronization? (this is currently under debate).

* Each external device should get an own task, so if you have multiple
serial lines, each should get an own task. 

* A command line interpreter/user interface needs an own task. 

* Disk access or even large queue handling could benefit from an own
task. 

* Very heavy, low priority calculations could be done in the NULL/Idle
task. 

* A clock task might also be useful to offload the workload from the
timer interrupt service routine (i.e. handle time of day and calendar
and also control timeouts and other time related functions). 

In a typical situation, these tasks should be quite sufficient.

However, in situations with a limited direct addressability (say 64
KiB) combined with a MMU and a much larger physical address space, it
can be a good idea to split to chunks to less than 64 KiB, even if the
functionality would not absolutely require it.

Paul

On 2007-06-08, Paul Keinanen <keinanen@sci.fi> wrote:

>>We're designing a new system using an RTOS.  Everyone on the
>>team has worked with an RTOS before, but none of us has ever
>>designed a system.  One thing I'm concerned with is we may end
>>up with too many tasks.  
>
> I have used this rule of thumb (sic) for decades: Keep the
> number of tasks below 11 so you can count the tasks with your
> fingers.

In some of the systems I work on there can easily be 70+ task
instances (a tx and rx task for each of 32 serial ports gets
you to 64 right away).  If you want to count task "functions"
in the souce code, there have probably never been more than 6-8
in anything I've ever worked on.

-- 
Grant Edwards                   grante             Yow! Can you MAIL a BEAN
                                  at               CAKE?
                               visi.com            

In news:9d5j63l175hlouu53rv4r3ehen17o3rpbn@4ax.com timestamped Fri, 08
Jun 2007 23:10:33 +0300, Paul Keinanen <keinanen@sci.fi> posted a
rather helpful response which included:
     "[..]
     
     As long as you have a clear system, in which task owns a specific data
     set (i.e. is allowed to modify it) and use as much atomic data types
     as possible, the need for task synchronisation primitives is reduced
     and also the risk for priority inversions and other deadlock
     situations is minimised.
     
     [..]"

Making your system clear will help you to design it such that priority
inversions will be less likely, but if your system has a resource
shared by tasks of different priorities, then atomic data types can
not prevent a priority inversion here.

Regards,
Colin Paul Gloster

On 10 Jun 2007 12:31:32 GMT, Colin Paul Gloster
<Colin_Paul_Gloster@ACM.org> wrote:

>In news:9d5j63l175hlouu53rv4r3ehen17o3rpbn@4ax.com timestamped Fri, 08
>Jun 2007 23:10:33 +0300, Paul Keinanen <keinanen@sci.fi> posted a
>rather helpful response which included:
>     "[..]
>     
>     As long as you have a clear system, in which task owns a specific data
>     set (i.e. is allowed to modify it) and use as much atomic data types
>     as possible, the need for task synchronisation primitives is reduced
>     and also the risk for priority inversions and other deadlock
>     situations is minimised.
>     
>     [..]"
>
>Making your system clear will help you to design it such that priority
>inversions will be less likely, but if your system has a resource
>shared by tasks of different priorities, then atomic data types can
>not prevent a priority inversion here.

You only get priority inversions, if some of the tasks lock that
resource and hence some other task may have to wait for that resource.
In many cases the program and the data structures can be designed in
such a way that the locking is not required, thus eliminating the
possibility of priority inversion.

Paul

"Paul Keinanen" <keinanen@sci.fi> wrote in message 
news:9d5j63l175hlouu53rv4r3ehen17o3rpbn@4ax.com...
> On Fri, 08 Jun 2007 05:47:24 -0700, james.ro123@yahoo.com wrote:
>
>>Hi,
>>
>>We're designing a new system using an RTOS.  Everyone on the team has
>>worked with an RTOS before, but none of us has ever designed a
>>system.  One thing I'm concerned with is we may end up with too many
>>tasks.
>
> I have used this rule of thumb (sic) for decades: Keep the number of
> tasks below 11 so you can count the tasks with your fingers. In
> exceptional cases up to 20 tasks could be used, but my colleagues
> might not like if I take my socks off and use also my toes to count
> the tasks :-).

They'd like it even less if you had 21 tasks ;-) 

"Vladimir Vassilevsky" <antispam_bogus@hotmail.com> wrote in message 
news:8Igai.24847$YL5.18511@newssvr29.news.prodigy.net...
> Steve at fivetrees wrote:
>>> Avoiding the state machines is the whole point of multitasking.
>> Heh - I avoid (or implement) multitasking using state machines ;).

> for(;;) Do_Everything() works only for the small projects.

I hear this often, but I disagree. I've done some very large/complex 
systems using cooperative multitasking. As always, it's a question of 
breaking complex things down into a collection of simple things.

> > (Main advantage: synchronicity. Secondary advantage: simplicity.)
>
> Windows 3.x was all synchronous single task system. That's one of the 
> reasons why the programming for it was so miserable.

Ah, if you're talking about general-purpose programmable systems, then 
I'd agree. I'm referring to embedded systems.

I *would* concede, however, that using an RTOS makes good sense where 
large teams are involved. The discipline required to successfully write 
cooperative tasks is somewhat relaxed - the brute-force context swapping 
ensures each task gets a fair shake. And it can be easier to partition 
tasks. However, cooperative multitasking shouldn't be dismissed - 
properly written, it's (obviously) more efficient, less demanding of the 
hardware, and the discipline required to understand the requirements and 
design it properly in the first place (rather than throw code at an 
RTOS) tends to make for a more solid system.

YMMV ;).

Steve
http://www.fivetrees.com 

On Fri, 08 Jun 2007 18:27:05 +0100, Steve at fivetrees wrote:

> Heh - I avoid (or implement) multitasking using state machines ;).
> 
> (Main advantage: synchronicity. Secondary advantage: simplicity.)

Me too, for the same reasons - synchronicity and simplicity. With
judicious use of interrupts, it is my favoured approach. 

I have seen an RTOS approach running on a 32-bit system, then ported
to a state machine to get it to work as required - I'm sure there are
examples of the other way around too. 

And the cut off point between the two approaches (for embedded systems)
is? .....

I have seen projects 20K+ lines of code that use a state machine method
very well, with very good performance/clarity (and therefore
maintainability). The point at which the state machine breaks down 
is of course due to other factors, other than just LOC. And not well
defined. Otherwise, projects wouldn't start with one approach, and then
switch over to the other.

Regards,

Paul.
    

On Mon, 11 Jun 2007 09:32:04 +0100, "Tom Lucas"
<news@REMOVE_tlcs_THIS_dot_TO_fsnet_REPLY_dot_co.uk> wrote:

>"Paul Keinanen" <keinanen@sci.fi> wrote in message 
>news:9d5j63l175hlouu53rv4r3ehen17o3rpbn@4ax.com...
>> On Fri, 08 Jun 2007 05:47:24 -0700, james.ro123@yahoo.com wrote:
>>
>>>Hi,
>>>
>>>We're designing a new system using an RTOS.  Everyone on the team has
>>>worked with an RTOS before, but none of us has ever designed a
>>>system.  One thing I'm concerned with is we may end up with too many
>>>tasks.
>>
>> I have used this rule of thumb (sic) for decades: Keep the number of
>> tasks below 11 so you can count the tasks with your fingers. In
>> exceptional cases up to 20 tasks could be used, but my colleagues
>> might not like if I take my socks off and use also my toes to count
>> the tasks :-).
>
>They'd like it even less if you had 21 tasks ;-) 

Did you ask my male or female colleagues :-)

Paul

On Jun 8, 8:47 am, james.ro...@yahoo.com wrote:
> Hi,
>
> We're designing a new system using an RTOS.  Everyone on the team has
> worked with an RTOS before, but none of us has ever designed a
> system.  One thing I'm concerned with is we may end up with too many
> tasks.  I reviewed my papers/magazines and searched the web for half a
> day and didn't get much info.  So, for those of you who've been
> through this before, I have a couple of basic questions:
>
> 1)  What are the disadvantages of a lot of tasks (besides inefficient
> stack usage)?  I'm concerned it may exacerbate deadlock, make it
> harder to debug, create synchronization issues, etc.
>
> 2)  How do you decide when to create a task?  We decided to create a
> "task creation criteria" to aid us.  Right now it has the following:
> a) any defined events in the system (button presses, etc.) should be
> in a task, b) anything that is going to take a while to complete (i.e.
> background processing) should be in a task and c) could placing stuff
> in a task aid in synchronization? (this is currently under debate).
>
> Thanks much for your input!!
>
> Jim

I'd like to thank everyone for their responses.   Friday, I'll
summarize all this and present it to the team.

Thanks again!


Jim

There are a lot of good ideas here, so I thought I'd just throw out a
few resources:

Software Design Methods of Concurrent and Real-Time Systems by Hassan
Gomaa is a great resource (ISBN 0-201-52577-1).

Operating Systems by Gary Nutt (ISBN 0-201-77344-9) has a really great
dead-lock and synchronization section.

OK, some advice here:

1. Make a rough pass over the entire system first and run that system
at speed. It will give you a good idea of the bottle-necks and any
potential dead-lock scenarios. Instead of computations, just use busy
waits that can emulate the time aspect of each task.

2. Identify the data sources and sinks. If possible make sure the
system "runs down hill."