Debugging RTOS problems in embedded systems

Op Thu, 05 Jul 2007 16:15:38 +0200 schreef Dennis <dennis@nowhere.net>:
> Boudewijn Dijkstra wrote:
>
>>> 4)Problems related with priority setting
>> Never heard of this.
>>
> Search "priority inversion". Most famously it almost took out
> one of the Mars landers - even tho the problem had been known
> for decades.

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.


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

On 2007-07-05, Boudewijn Dijkstra <boudewijn@indes.com> wrote:
> Op Thu, 05 Jul 2007 16:15:38 +0200 schreef Dennis <dennis@nowhere.net>:
>> Boudewijn Dijkstra wrote:
>>
>>>> 4)Problems related with priority setting
>>> Never heard of this.
>>>
>> Search "priority inversion". Most famously it almost took out
>> one of the Mars landers - even tho the problem had been known
>> for decades.
>
> 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.

> 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.  I can just hear the engineering team explaining the
design:

  "Of course the device needs 34 Ethernet interfaces: 2 for
   SNMP (1 for the server, 1 to send alarms), 3 for the web
   servers (one for each CPU that's running a task than needs
   to be visible via the web), 1 for the tftp server, 6 for
   factory testing (one for each CPU), 1 for remote logging, 1
   for outbound e-mail, and 2 for each pair of CPUs that need
   to talk to each other.  We're going to be competing against
   a device with the same features but only 1 CPU and 1
   Ethernet interface, so the competitor's costs are about 5%
   of ours, but we think it's worth it to avoid the evils of
   shared resources."

-- 
Grant Edwards                   grante             Yow! OVER the underpass!
                                  at               UNDER the overpass!
                               visi.com            Around the FUTURE and
                                                   BEYOND REPAIR!!

Boudewijn Dijkstra wrote:
> schreef Dennis <dennis@nowhere.net>:
>> Boudewijn Dijkstra wrote:
>>
>>>> 4)Problems related with priority setting
>>> Never heard of this.
>>>
>> Search "priority inversion". Most famously it almost took out
>> one of the Mars landers - even tho the problem had been known
>> for decades.
> 
> 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.

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

Op Thu, 05 Jul 2007 17:10:47 +0200 schreef Grant Edwards <grante@visi.com>:
> On 2007-07-05, Boudewijn Dijkstra <boudewijn@indes.com> wrote:
>> Op Thu, 05 Jul 2007 16:15:38 +0200 schreef Dennis <dennis@nowhere.net>:
>>> Boudewijn Dijkstra wrote:
>>>
>>>>> 4)Problems related with priority setting
>>>> Never heard of this.
>>>>
>>> Search "priority inversion". Most famously it almost took out
>>> one of the Mars landers - even tho the problem had been known
>>> for decades.
>>
>> 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.

>> 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.  Yes, they have some  
overhead, but not in the order of handfulls of logic units.





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

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.

You're design projects come with documentation specifying how
everyting is supposed to be designed?  Must be nice.

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

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


-- 
Grant Edwards                   grante             Yow! !  I'm in a very
                                  at               clever and adorable INSANE
                               visi.com            ASYLUM!!

On Jul 5, 12:02 pm, Grant Edwards <gra...@visi.com> wrote:
>
> 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".

I sense an interesting (or maybe "interesting") discussion coming...

On 2007-07-05, Mike Silva <snarflemike@yahoo.com> wrote:
> On Jul 5, 12:02 pm, Grant Edwards <gra...@visi.com> wrote:
>>
>> 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".
>
> I sense an interesting (or maybe "interesting") discussion coming...

I think you misspelled "futile"...

-- 
Grant Edwards                   grante             Yow! Is this going to
                                  at               involve RAW human ecstasy?
                               visi.com            

On 2007-07-05, CBFalconer <cbfalconer@yahoo.com> wrote:
> Boudewijn Dijkstra wrote:
>> schreef Dennis <dennis@nowhere.net>:
>>> Boudewijn Dijkstra wrote:
>>>
>>>>> 4)Problems related with priority setting
>>>> Never heard of this.
>>>>
>>> Search "priority inversion". Most famously it almost took out
>>> one of the Mars landers - even tho the problem had been known
>>> for decades.
>> 
>> 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.

Full-duplex Ethernet?

But you're still sharing DMA buffers between a task and the
Ethernet controller.

I guess the only answer is a giant super-loop with no
interrupts or DMA.

-- 
Grant Edwards                   grante             Yow! Pardon me, but do you
                                  at               know what it means to be
                               visi.com            TRULY ONE with your BOOTH!

Op Thu, 05 Jul 2007 17:22:09 +0200 schreef CBFalconer  
<cbfalconer@yahoo.com>:

> Boudewijn Dijkstra wrote:
>> schreef Dennis <dennis@nowhere.net>:
>>> Boudewijn Dijkstra wrote:
>>>
>>>>> 4)Problems related with priority setting
>>>> Never heard of this.
>>>>
>>> Search "priority inversion". Most famously it almost took out
>>> one of the Mars landers - even tho the problem had been known
>>> for decades.
>>
>> 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.

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.



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

Boudewijn Dijkstra wrote:
> CBFalconer <cbfalconer@yahoo.com>:
>> Boudewijn Dijkstra wrote:
>>> schreef Dennis <dennis@nowhere.net>:
>>>> Boudewijn Dijkstra wrote:
>>>>
>>>>>> 4)Problems related with priority setting
>>>>> Never heard of this.
>>>>>
>>>> Search "priority inversion". Most famously it almost took out
>>>> one of the Mars landers - even tho the problem had been known
>>>> for decades.
>>>
>>> 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.
> 
> 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.

I see.  You want to avoid the whole problem by handing it to a
magic OS function, with no understanding of the problems involved. 
You will go far.

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