RE: [ECOS] Multiple Inheritance used in eCos class Cyg_Thread

RE: [ECOS] Multiple Inheritance used in eCos class Cyg_Thread

[Donald Walton]

I apologize for the retrasmission of this message.  It was originally
sent to the wrong eCos group.


I would be interested to know the type of testing eCos has been through.
If it has been successfully tested as part of an embedded aviation
system, I would agree with you.  If it has been tested as part of the
embedded system for a printer or digital camera, I would have to
disagree with you.

When it comes to developing embedded systems that are safety critical,
one cannot be too careful.

If there is little interest in using eCos in safety critical systems,
leave it as it is.  However, companies and individuals planning to use
it in areas where safety is important may want to rework the area where
there is multiple inheritance or plan to accept the cost of extensive
testing.  In such situations, this can be an additional risk factor for
a project.

I was hesitant to raise this subject, but I am delighted to see the
discussion that has grown out of my initial query.  Discussions such as
this can only serve to make eCos a more reliable and relevant real-time
operating system in embedded system development.

Have a great day,
Don Walton

Defense Research Associates, Inc.
3915 Germany Lane, Suite 102
Beavercreek, OH 45431
(937)431-1644 ext. 118


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Multiple Inheritance used in eCos class Cyg_Thread

[Fabian Scheler]

> I was hesitant to raise this subject, but I am delighted to see the
> discussion that has grown out of my initial query.  Discussions such as
> this can only serve to make eCos a more reliable and relevant real-time
> operating system in embedded system development.

Another issue that would have to be addressed to improve the real-time
capabilities of eCos is the execution order off dsrs, as these are
just executed in the order of their activation (or the reversed
order?). In an event-triggered system, this might lead to hard to
predict or hard to estimate delays of high priority events as they are
normally mapped to interrupts, ie. isrs/dsrs.

Ciao, Fabian

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Multiple Inheritance used in eCos class Cyg_Thread

[Nick Garnett]

Donald Walton <dwalton@dramail.com> writes:

> I would be interested to know the type of testing eCos has been through.
> If it has been successfully tested as part of an embedded aviation
> system, I would agree with you.  If it has been tested as part of the
> embedded system for a printer or digital camera, I would have to
> disagree with you.

eCos has been used is a number of mission critical applications
including automotive and satellite systems. It has certainly been used
in aviation, but probably not in anything safety critical.

> 
> When it comes to developing embedded systems that are safety critical,
> one cannot be too careful.
> 
> If there is little interest in using eCos in safety critical systems,
> leave it as it is.  However, companies and individuals planning to use
> it in areas where safety is important may want to rework the area where
> there is multiple inheritance or plan to accept the cost of extensive
> testing.  In such situations, this can be an additional risk factor for
> a project.

The edict against multiple inheritance is presumably against using it
to develop new application code. In the case of eCos, MI is used only
within the kernel, applications do not have access to the classes
involved, and it is used in a very restricted and controlled
way. There is absolutely no possibility of application code
encountering MI under normal circumstances.

Looking at it a different way: if eCos were a closed source OS,
distributed only as a binary library, then you would not know that MI
were being used internally. The same is true now, even though you can
see the source, the use of MI is not visible.

Very little development now goes on in the kernel, it has been stable
for many years. So the fear that some sort of programming mistake
using MI will introduce a bug is very remote. Changing the kernel to
eliminate MI is much more likely to destabilize it.


-- 
Nick Garnett                                     eCos Kernel Architect
http://www.ecoscentric.com                The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Multiple Inheritance used in eCos class Cyg_Thread

[Donald Walton]

Thanks for your insightful response.

I'll pass the responses along to my bosses and see which way they want
to process from here.

Have a great day,
Don Walton

On Thu, 2006-12-14 at 16:14 +0000, Nick Garnett wrote:
> Donald Walton <dwalton@dramail.com> writes:
> 
> > I would be interested to know the type of testing eCos has been through.
> > If it has been successfully tested as part of an embedded aviation
> > system, I would agree with you.  If it has been tested as part of the
> > embedded system for a printer or digital camera, I would have to
> > disagree with you.
> 
> eCos has been used is a number of mission critical applications
> including automotive and satellite systems. It has certainly been used
> in aviation, but probably not in anything safety critical.
> 
> > 
> > When it comes to developing embedded systems that are safety critical,
> > one cannot be too careful.
> > 
> > If there is little interest in using eCos in safety critical systems,
> > leave it as it is.  However, companies and individuals planning to use
> > it in areas where safety is important may want to rework the area where
> > there is multiple inheritance or plan to accept the cost of extensive
> > testing.  In such situations, this can be an additional risk factor for
> > a project.
> 
> The edict against multiple inheritance is presumably against using it
> to develop new application code. In the case of eCos, MI is used only
> within the kernel, applications do not have access to the classes
> involved, and it is used in a very restricted and controlled
> way. There is absolutely no possibility of application code
> encountering MI under normal circumstances.
> 
> Looking at it a different way: if eCos were a closed source OS,
> distributed only as a binary library, then you would not know that MI
> were being used internally. The same is true now, even though you can
> see the source, the use of MI is not visible.
> 
> Very little development now goes on in the kernel, it has been stable
> for many years. So the fear that some sort of programming mistake
> using MI will introduce a bug is very remote. Changing the kernel to
> eliminate MI is much more likely to destabilize it.
> 
> 
> -- 
> Nick Garnett                                     eCos Kernel Architect
> http://www.ecoscentric.com                The eCos and RedBoot experts
> 
> 

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Multiple Inheritance used in eCos class Cyg_Thread

[Nick Garnett]

"Fabian Scheler" <fabian.scheler@gmail.com> writes:

> > I was hesitant to raise this subject, but I am delighted to see the
> > discussion that has grown out of my initial query.  Discussions such as
> > this can only serve to make eCos a more reliable and relevant real-time
> > operating system in embedded system development.
> 
> Another issue that would have to be addressed to improve the real-time
> capabilities of eCos is the execution order off dsrs, as these are
> just executed in the order of their activation (or the reversed
> order?). In an event-triggered system, this might lead to hard to
> predict or hard to estimate delays of high priority events as they are
> normally mapped to interrupts, ie. isrs/dsrs.

This is not an issue if DSRs are used properly. For a start, any
prioritizable processing should be done in threads. That is what they
are there for. DSRs exist to interface between ISRs and
threads. Consequently they should only contain a few lines of code,
just a call to signal a condition variable or a semaphore, nothing
more.

If we prioritize DSRs we need to consider what priority space they
should occupy. There seem to be two options: hardware interrupt
priorities or thread priorities. The patch to make DSRs execute in
activation order means that they now track interrupt priorities fairly
closely, any extra code here would be a lot of work to very little
effect.

DSRs are not preemptable, and currently all pending DSRs must run to
completion before any thread gets to execute. So as far as worst case
thread response time is concerned, prioritizing DSRs amongst
themselves will have no effect. So the only alternative approach would
be to prioritize DSRs in the same space as threads so that only DSRs
of equal or higher priority than the current thread would be allowed
to execute.

However, this approach still doesn't allow DSRs to be preempted, and
would introduce a whole range of other issues regarding priority
inversion and DSR starvation. Threads are preemptable and
prioritizable, and any code that needs those sorts of properties
should go into threads. We should not try to add those properties to
DSRs.


On a philosophical note, I am beginning to wonder whether it was a
mistake to expose a functional interface to the DSR mechanism, since
it tempts people to write code in them. In hindsight the interface
should have been a simple signal a condition variable/semaphore
operation. I think things would have been much simpler.


-- 
Nick Garnett                                     eCos Kernel Architect
http://www.ecoscentric.com                The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Multiple Inheritance used in eCos class Cyg_Thread

[Fabian Scheler]

> DSRs are not preemptable, and currently all pending DSRs must run to
> completion before any thread gets to execute. So as far as worst case
> thread response time is concerned, prioritizing DSRs amongst
> themselves will have no effect. So the only alternative approach would
> be to prioritize DSRs in the same space as threads so that only DSRs
> of equal or higher priority than the current thread would be allowed
> to execute.
>
> However, this approach still doesn't allow DSRs to be preempted, and
> would introduce a whole range of other issues regarding priority
> inversion and DSR starvation. Threads are preemptable and
> prioritizable, and any code that needs those sorts of properties
> should go into threads. We should not try to add those properties to
> DSRs.

that's true, I have to admit I have been completely oblivious of this
point during my thoughts ...

> On a philosophical note, I am beginning to wonder whether it was a
> mistake to expose a functional interface to the DSR mechanism, since
> it tempts people to write code in them. In hindsight the interface
> should have been a simple signal a condition variable/semaphore
> operation. I think things would have been much simpler.

but I would not throw the DSR-Interface away, because there may be
some events that could be handled with just a few lines of code
executed in a dsr.

Ciao, Fabian

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Multiple Inheritance used in eCos class Cyg_Thread

[Paul D. DeRocco]

> From: Don Walton [mailto:dwalton@dramail.com]
>
> I would be interested to know the type of testing eCos has been
> through.  If it has been successfully tested as part of an
> embedded aviation system, I would agree with you.  If it has been
> tested as part of the embedded system for a printer or digital
> camera, I would have to disagree with you.

My point isn't that eCos has been sufficiently tested for any particular
application, but that the multiple inheritance bits aren't any less tested
than the rest of the system, since lots of people have used it. And the bugs
I see discussed here don't seem to be in that particular area.

If you're afraid to use eCos because some small piece of it uses multiple
inheritance, then I'm not sure why you wouldn't be afraid to use the rest of
it. I think that if I were going for extreme reliability, I'd spend the
bucks and start with something like Integrity or VxWorks, which has been
qualified for military apps. Indeed, I've been trying to get one medical
device company I consult for to abandon eCos for just that reason.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Multiple Inheritance used in eCos class Cyg_Thread

[Paul D. DeRocco]

> From: Donald Walton
>
> This is in no way intended to be an edict.
>
> However, there are environments where object oriented software using
> multiple inheritance is discouraged.  Using multiple inheritance in such
> environments can lead to costly testing to prove that the multiple
> inheritance scenario is functioning exactly as it should without error.
>
> One environment is embedded systems for the aviation industry.  In the
> United States, the Federal Aviation Administration has set out
> guidelines for software development, DO-178B.  The FAA has come out with
> additional guidelines for object oriented software nixing the use of
> multiple inheritance in safety critical system software.
>
> Being aware of this issue, the company I work for does have, as part of
> the software design document, the prohibition of the use of multiple
> inheritance in any embedded system.

But the only multiple inheritance would be inside eCos, where it has already
been tested as well as any other part of eCos. It would probably be more
dangerous to rewrite those parts of eCos to conform to that standard, than
simply to use the already tested eCos as a black box without concern for
such details of its contents.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Multiple Inheritance used in eCos class Cyg_Thread

[Donald Walton]

This is in no way intended to be an edict.

However, there are environments where object oriented software using
multiple inheritance is discouraged.  Using multiple inheritance in such
environments can lead to costly testing to prove that the multiple
inheritance scenario is functioning exactly as it should without error.

One environment is embedded systems for the aviation industry.  In the
United States, the Federal Aviation Administration has set out
guidelines for software development, DO-178B.  The FAA has come out with
additional guidelines for object oriented software nixing the use of
multiple inheritance in safety critical system software.

Being aware of this issue, the company I work for does have, as part of
the software design document, the prohibition of the use of multiple
inheritance in any embedded system.

Have a great day,
Don Walton


On Wed, 2006-12-13 at 10:49 -0700, Gary Thomas wrote:
> Donald Walton wrote:
> > I have started looking more closely at the core of eCos.  I noticed that
> > multiple inheritance appears to be used in connection with the
> > Cyg_Thread class.  The arena I am working in does not permit multiple
> > inheritance.
> 
> What does this mean?  A design edict?  "Thall shalt not touch multiple inheritance"?
> 
> -- 
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
> 

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Multiple Inheritance used in eCos class Cyg_Thread

[Gary Thomas]

Donald Walton wrote:
> I have started looking more closely at the core of eCos.  I noticed that
> multiple inheritance appears to be used in connection with the
> Cyg_Thread class.  The arena I am working in does not permit multiple
> inheritance.

What does this mean?  A design edict?  "Thall shalt not touch multiple inheritance"?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Multiple Inheritance used in eCos class Cyg_Thread

[Donald Walton]

I have started looking more closely at the core of eCos.  I noticed that
multiple inheritance appears to be used in connection with the
Cyg_Thread class.  The arena I am working in does not permit multiple
inheritance.

This raises the following questions:

Would it be difficult task to remove the multiple inheritance for the
Cyg_Thread class?

Would eliminating the multiple inheritance adversely affect the
operation of eCos?

Thanks in advance for your comments and insight,
Don Walton

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss