This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: One process with multiple threads??


graham_k wrote:
> [Threads v processes]
> Sounds riskier, but probably easier to implement. If one crashes, it takes
> out the whole system. But, well, if they have separate address space, if one
> crashes you still ought to detect it and restart either the process or the
> device.

Indeed, it's a significant complexity reduction. If you are sure that your
application is written carefully enough to not need robust segregation
between processes, you don't need an OS that provides it and all the
attendant complexity. If you can reduce your code size, this might mean you
need a smaller flash part, less SDRAM, a less powerful CPU core: save a few
cents in your bill of materials, which in turn translates to a huge saving
in a mass-produced consumer device.

> In practise, we just tend to test to death & hope that this sort of thing
> never happens ;-)  

In eCos, everything runs in supervisor (kernel) mode. You can take 42, cast
it to a char* and write to the memory it now points to, if that's somehow a
useful thing to do on your hardware. To abuse a certain phrase, the gun is
not so much pointed at your feet, but continually tracking your feet
wherever you may run to.

Practice good code hygiene, carefully define your internal interfaces, and
always check for errors; for example, malloc() can - in an embedded target,
most likely will - return NULL at some inconvenient moment. Keep It Simple,
too; you can always go back and optimise later if you find you need to. If
something goes particularly wrong - what one might think of as segfault or
application-error territory on a desktop OS - you might cause a CPU
exception or trap, which your hardware might well allow you to set up a
handler for. But you might not; as memory protection is usually turned off
in eCos, you could (for example) scribble all over the C stack and drop the
CPU into an infinite loop. For this reason, watchdog timers have their
proponents. In any event, hypothetically, if a thread has crashed badly and
your RAM contents are potentially corrupted, how practical is it to attempt
a recovery short of rebooting anyway?

In short: With the power comes responsibility! :)


Ross

-- 
Embedded Software Engineer, eCosCentric Limited.
Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK.
Registered in England no. 4422071.                  www.ecoscentric.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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]