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
RTOS system design--how many tasks?
Started by ●June 8, 2007
Reply by ●June 8, 20072007-06-08
The main thing that comes with more tasks is an increased amount of overhead due to the OS switching more often. If two pieces of code work towards the same goal then they should be in the same task. If two pieces of code only need to share data, but perform differents tasks with the data, then each should get its own task. Pretty simple. As far as synchronization goes, it is easier to synchronize inside of a task than it is to synchronize using inter-process communication, and the overhead associated with it is far less. Also, if you are dealing with a hard real-time system scheduled with say a rate monotonic policy, then the utilization bound can be severely impacted by the number and utilizations of the tasks. ---Matthew Hicks> 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 >
Reply by ●June 8, 20072007-06-08
Op Fri, 08 Jun 2007 14:47:24 +0200 schreef <james.ro123@yahoo.com>:> 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)?This all depends on the scheduling algorithm, the ratio between no. of tasks and priorities and your methods of inter-task communication and synchronisation.> I'm concerned it may exacerbate deadlock, make it > harder to debug, create synchronization issues, etc.Deadlock can be avoided altogether by proper system design. If your debugging setup can query the current task after hitting a breakpoint, then it is not harder to debug. If your debugging setup can query synchronisation and communication primitives, then that also is not an issue.> 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 andc) could placing stuff > in a task aid in synchronization? (this is currently under debate).If this means that you can have too few tasks, then yes. Otherwise explain "stuff". -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/
Reply by ●June 8, 20072007-06-08
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 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.Memory is cheap these days so inefficient stack usage isn't something to be too concerned about. Time is still expensive, though, so spending too much time switching between tasks is a valid concern.>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).Everything must be in a task or an ISR if tasking is to work properly. The question, then, is not whether portions of processing should be in tasks but how to organize tasks and assign processing to those tasks. My designs tend to associate tasks with interrupt sourcess, often with one task per interrupt but multiple interrupts may be associated with single tasks, too. Note that timers are interrupt sources and that tasks may be entirely timer driven.>Thanks much for your input!!HTH -- ======================================================================== Michael Kesti | "And like, one and one don't make | two, one and one make one." mrkesti at hotmail dot com | - The Who, Bargain
Reply by ●June 8, 20072007-06-08
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.The whole purpose of multitasking is the simplification of the development. Of course, it comes with some overhead. Having too many tasks actually makes the things more complicated. In my projects, it is usually about 10 separate threads.> 1) What are the disadvantages of a lot of tasks (besides inefficient > stack usage)?The excessive task switching and message passing between the tasks is wasting the CPU cycles, too.> 2) How do you decide when to create a task?If there is a job which has to be done from time to time asynchronously to the other jobs, it is good to implement this job as a separate task. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●June 8, 20072007-06-08
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 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!!I'd put the whole user interface into one task. The user is sufficiently slow to not press multiple buttons at once. The alternate solution to a task is a statemachine for a closed process. Statemachines are more complex than the linear code of a task. So basically you trade complexity against efficiency. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net
Reply by ●June 8, 20072007-06-08
Rene Tschaggelar wrote:> > I'd put the whole user interface into one task. > The user is sufficiently slow to not press > multiple buttons at once.The user interface consists of the two asynchronous processes at the least: the input and the output. Thus it is natural to have the two threads for that. Other then that, there could be many threads dealing with the graphics engine, etc.> > The alternate solution to a task is a statemachine > for a closed process. Statemachines are more complex > than the linear code of a task. So basically you > trade complexity against efficiency.Yes. Avoiding the state machines is the whole point of multitasking. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●June 8, 20072007-06-08
"Vladimir Vassilevsky" <antispam_bogus@hotmail.com> wrote in message news:YSdai.7289$y_7.639@newssvr27.news.prodigy.net...> Rene Tschaggelar wrote: >> >> The alternate solution to a task is a statemachine >> for a closed process. Statemachines are more complex >> than the linear code of a task. So basically you >> trade complexity against efficiency. > > Yes. Avoiding the state machines is the whole point of multitasking.Heh - I avoid (or implement) multitasking using state machines ;). (Main advantage: synchronicity. Secondary advantage: simplicity.) Steve http://www.fivetrees.com
Reply by ●June 8, 20072007-06-08
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. The amount of money paid is generally proportional to the size of the project. Thus multitasking is the way to go :) > (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. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●June 8, 20072007-06-08
james.ro123@yahoo.com writes:> 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.Others have noted the cost of task switching. I would have thought this was the least of your worries unless you have a slow CPU, a poor RTOS or very high frequencies -- VxWorks on a 1 GHz PPC switches in a small number of us. Having lots of tasks 'because you can' without a clear design strategy of tasking/synchronisation is a good road to disaster.> 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).We use tasks: * to block on input (an interrupt, a network packet). * to handle long processes in the background (this is rare for us). * to support real-time response requirements, where non-real-time event processing is too unconstrained. * to support non-real-time event processing. * (rarely!) to support large stack requirements. The last is a bit odd, but easy in Ada -- procedure Foo is task type T is pragma Storage_Size (1_000_000); entry Start; end T; task body T is ... end T; begin -- setup T.Start; -- blocks here until T terminates end Foo;