Debugging RTOS problems in embedded systems

Boudewijn Dijkstra wrote:

> Without a shared resource, the producer and consumer can simply become 
> sender and receiver of event objects, messages or signals, passed safely 
> by the RTOS, a library or by a framework.

In other words, you say you solved the problem by handing it over to 
somebody else.

On 2007-07-05, Hans-Bernhard Br&#4294967295;ker <HBBroeker@t-online.de> wrote:
> Boudewijn Dijkstra wrote:
>
>> Without a shared resource, the producer and consumer can
>> simply become sender and receiver of event objects, messages
>> or signals, passed safely by the RTOS, a library or by a
>> framework.
>
> In other words, you say you solved the problem by handing it
> over to somebody else.

  "You're very clever, young man, very clever," said the old
   lady. "But it's turtles all the way down!"

http://en.wikipedia.org/wiki/Turtles_all_the_way_down
 
-- 
Grant Edwards                   grante             Yow! I represent a
                                  at               sardine!!
                               visi.com            

On 2007-07-05, Boudewijn Dijkstra <boudewijn@indes.com> wrote:

>> Please explain how to connect a producer and a consumer without a
>> shared resource.
>
> Without a shared resource, the producer and consumer can simply become  
> sender and receiver of event objects, messages or signals,

Event objects/queues? Messages? Signals? Can you say "shared
resources"?  Very good! I knew you could.

> passed safely by the RTOS, a library or by a framework.

They're _all_still_shared_resources_.

-- 
Grant Edwards                   grante             Yow!  Just imagine you're
                                  at               entering a state-of-the-art
                               visi.com            CAR WASH!!

Op Thu, 05 Jul 2007 18:02:59 +0200 schreef Grant Edwards <grante@visi.com>:
> On 2007-07-05, Boudewijn Dijkstra <boudewijn@indes.com> wrote:
>
>>>> Ah, but priority inversion I heard of.  Priority inversion is not
>>>> explicitly 'setting' the scheduler priority, as the OP implied, only  
>>>> the apparant execution priority.
>>>
>>> It's also possible to introduce bugs by explicitly setting
>>> priorities incorrectly.  Sometimes the "intuitive" priority
>>> settings don't work the way you expect them to. Um, not that
>>> _I've_ ever had that problem, of course.
>
>> Preferring intuition over documentation is always like walking
>> on thin ice.
>
> [Your] design projects come with documentation specifying how
> everyting is supposed to be designed?  Must be nice.

Then perhaps I didn't understand completely.  I thought you meant to say  
that your scheduler didn't behave as you expected intuitively.

>>>> Another reason not to share resources between tasks.
>>>
>>> I suppose you can just throw handfulls of CPUs, memory chips,
>>> network interfaces, and whatnot at everything. That gets pretty
>>> expensive.  [...snip elaborate proposterousity...]
>>
>> You could also (re)activate your brain and think about realistic ways to
>> allow several tasks to use (not share) a resource.
>
> How is several tasks using a resource not sharing resources.

Perhaps a better term in lieu of my 'to share' is 'to share directly'.  A  
task can use a resource without knowing or caring how many others are  
using it, and therefore without the task knowing whether it is 'sharing'  
the resource.  This is the case when the resource is encapsulated by a  
service task with a thread-safe communication interface.

>> Yes, they have some overhead, but not in the order of
>> handfulls of logic units.
>
> I'm a little baffled as to how multiple tasks are going to "use
> a resource" (e.g. CPU, peripheral, data structure, memory pool)
> without that being "resource sharing".

You can become water from a tap without sharing the tap directly.



-- 
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/

Op Thu, 05 Jul 2007 23:56:48 +0200 schreef Hans-Bernhard Br�ker  
<HBBroeker@t-online.de>:
> Boudewijn Dijkstra wrote:
>
>> Without a shared resource, the producer and consumer can simply become  
>> sender and receiver of event objects, messages or signals, passed  
>> safely by the RTOS, a library or by a framework.
>
> In other words, you say you solved the problem by handing it over to  
> somebody else.

And that somebody has to do it right only once.  And then everybody can  
taste the fruit.  What's wrong with that?


-- 
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/

On Jul 2, 8:17 am, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
wrote:
> ssubbarayan wrote:
> > Dear All,
> > Most of us involved with RTOS projects in embedded systems need to
> > encounter at one point or other problems pertaining to real time
> > situations:
> > 1)DeadLocks
> > 2)Racing conditions
> > 3)Problems related to re-entrancy.
> > 4)Problems related with priority setting
>
> > What are the general debugging techniques used to uncover problems
> > related to above mentioned?
>
> There are the only two debugging tools for everything: the smart head
> and the assiduous ass. Nothing can help until you know what are you
> doing. And if you know how the stuff works, there should not be much of
> a need to debug it.
>
> I have earlier worked with windriver
>
> > Tornado and Vxworks,and I got a tool called Windview which will show
> > graphicaly the status of tasks as well as some analysis on timing.
>
> Those tools are no more then the glossy toys for the beginners. A debug
> printouts in the critical places and toggling LEDs is sufficient to
> verify the operation.
>
> VLV

Wow Vladmir... thats a pretty bold statement. Maybe if you're writing
software for something trivial all you need is an LED switch, but if
its anything more than the most trivial project you're wasting your
time looking at LEDs. When you have dozens of different processes
communicating different messages over different buses with different
protocols toggling an LED just won't do.
Take a look at Green Hills Software's PathAnalyzer. It takes windview
to a higher level. Instead of displaying just system events and
context switches it can display every function executed. You can
clearly see when a task comes in and executes unsafe code.

On Jul 5, 11:58 pm, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
> Op Thu, 05 Jul 2007 18:02:59 +0200 schreef Grant Edwards <gra...@visi.com>:
>
>
>
> > On 2007-07-05, Boudewijn Dijkstra <boudew...@indes.com> wrote:
>
> >>>> Ah, but priority inversion I heard of.  Priority inversion is not
> >>>> explicitly 'setting' the scheduler priority, as the OP implied, only
> >>>> the apparant execution priority.
>
> >>> It's also possible to introduce bugs by explicitly setting
> >>> priorities incorrectly.  Sometimes the "intuitive" priority
> >>> settings don't work the way you expect them to. Um, not that
> >>> _I've_ ever had that problem, of course.
>
> >> Preferring intuition over documentation is always like walking
> >> on thin ice.
>
> > [Your] design projects come with documentation specifying how
> > everyting is supposed to be designed?  Must be nice.
>
> Then perhaps I didn't understand completely.  I thought you meant to say
> that your scheduler didn't behave as you expected intuitively.
>
> >>>> Another reason not to share resources between tasks.
>
> >>> I suppose you can just throw handfulls of CPUs, memory chips,
> >>> network interfaces, and whatnot at everything. That gets pretty
> >>> expensive.  [...snip elaborate proposterousity...]
>
> >> You could also (re)activate your brain and think about realistic ways to
> >> allow several tasks to use (not share) a resource.
>
> > How is several tasks using a resource not sharing resources.
>
> Perhaps a better term in lieu of my 'to share' is 'to share directly'.  A
> task can use a resource without knowing or caring how many others are
> using it, and therefore without the task knowing whether it is 'sharing'
> the resource.  This is the case when the resource is encapsulated by a
> service task with a thread-safe communication interface.
>
> >> Yes, they have some overhead, but not in the order of
> >> handfulls of logic units.
>
> > I'm a little baffled as to how multiple tasks are going to "use
> > a resource" (e.g. CPU, peripheral, data structure, memory pool)
> > without that being "resource sharing".
>
> You can become water from a tap without sharing the tap directly.
>
> --
> Gemaakt met Opera's revolutionaire e-mailprogramma:  http://www.opera.com/mail/

> Perhaps a better term in lieu of my 'to share' is 'to share directly'.  A
> task can use a resource without knowing or caring how many others are
> using it, and therefore without the task knowing whether it is 'sharing'
> the resource.

There are three ways to threads/applications can share data. Messages
(like you mention), shared memory (which you forbid), and transactions
(only really exist in databases).  Both messages and shared memory can
easily suffer from deadlocks and race conditions... although shared
memory makes it easier to screw up. Transactions are the way of the
future... unfortunately they are the distant future.

Boudewijn Dijkstra wrote:
> schreef Grant Edwards <grante@visi.com>:
>> Boudewijn Dijkstra <boudewijn@indes.com> wrote:
>>
... snip ...
>>>
>>> You could also (re)activate your brain and think about realistic
>>> ways to allow several tasks to use (not share) a resource.
>>
>> How is several tasks using a resource not sharing resources.
> 
> Perhaps a better term in lieu of my 'to share' is 'to share
> directly'.  A task can use a resource without knowing or caring
> how many others are using it, and therefore without the task
> knowing whether it is 'sharing' the resource.  This is the case
> when the resource is encapsulated by a service task with a
> thread-safe communication interface.

In other words you are withdrawing your earlier inaccurate
statements, I presume.  It would be simpler to just admit it.  I
will admit a possibility of language difficulties.

-- 
 <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
 <http://www.securityfocus.com/columnists/423>
 <http://www.aaxnet.com/editor/edit043.html>
                        cbfalconer at maineline dot net



-- 
Posted via a free Usenet account from http://www.teranews.com

On 2007-07-06, Boudewijn Dijkstra <boudewijn@indes.com> wrote:
> Op Thu, 05 Jul 2007 23:56:48 +0200 schreef Hans-Bernhard Br&#4294967295;ker  
><HBBroeker@t-online.de>:
>> Boudewijn Dijkstra wrote:
>>
>>> Without a shared resource, the producer and consumer can simply become  
>>> sender and receiver of event objects, messages or signals, passed  
>>> safely by the RTOS, a library or by a framework.
>>
>> In other words, you say you solved the problem by handing it over to  
>> somebody else.
>
> And that somebody has to do it right only once.  And then everybody can  
> taste the fruit.  What's wrong with that?

There's nothing wrong with that.  It's actually rather a good
idea to used tested adn proven libraries to do resource
sharing.

Just don't pretend it's not resource sharing.

-- 
Grant Edwards                   grante             Yow! And then we could sit
                                  at               on the hoods of cars at
                               visi.com            stop lights!

On Thu, 05 Jul 2007 11:22:09 -0400, CBFalconer <cbfalconer@yahoo.com>
wrote:

>> 
>> Ah, but priority inversion I heard of.  Priority inversion is not
>> explicitly 'setting' the scheduler priority, as the OP implied,
>> only the apparant execution priority.  Another reason not to
>> share resources between tasks.
>
>Please explain how to connect a producer and a consumer without a
>shared resource.

Sure, there are always resources shared between tasks, at least the
cpu and its register.

The PI problem often arises if a resource (memory, peripheral) can be
controlled by more than one task (by way of a mutex/semaphore).

Using a dedicated task to control the resource minimizes the risk of a
PI because the resource itself has some kind of memory.

This all could be seen as some kind of priority inheritance with the
advantage, that not the OS decides but rather the resource itself.

I am new to RTOS design (only 8 years) and all this time I work with
direct message passing OS&#4294967295; an I never heared from any customers of a
PI problem.


-- 
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !