[ECOS] One process with multiple threads??

[ECOS] One process with multiple threads??

[graham_k]

Sorry to be such a n00b, but can someone please explain WikiPedia's statement
that "eCos (embedded configurable operating system) is an open source,
royalty-free, real-time operating system intended for embedded systems and
applications which need only one process with multiple threads"?

Why only one process? And presumably the thread are what I would think of as
processes in "normal" terminology?

I guess that what I am asking here is whether this is just a matter of
semantics (what's a process? what's a thread?) or if there are some
technical restrictions ...

Thank you very much in advance for any clarification.

-- 
View this message in context: http://www.nabble.com/One-process-with-multiple-threads---tp22841286p22841286.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.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] One process with multiple threads??

[Andrew Lunn]

On Wed, Apr 01, 2009 at 10:44:42PM -0700, graham_k wrote:
> 
> Sorry to be such a n00b, but can someone please explain WikiPedia's statement
> that "eCos (embedded configurable operating system) is an open source,
> royalty-free, real-time operating system intended for embedded systems and
> applications which need only one process with multiple threads"?
> 
> Why only one process? And presumably the thread are what I would think of as
> processes in "normal" terminology?
> 
> I guess that what I am asking here is whether this is just a matter of
> semantics (what's a process? what's a thread?) or if there are some
> technical restrictions ...
> 
> Thank you very much in advance for any clarification.

It is using the Unix/POSIX terminology.

In the unix world, processes are separated from each other. They have
separate memory space, they have separate signal handlers, file
descriptor space, sockets etc... If a process gets a segfault, just
that process dies.

However a process may have many POSIX threads. Within the process, the
threads have complete access to all the processes memory, signals,
file descriptors etc. If a thread gets a sigfault, the whole process
dies. 

eCos has no memory protection. All memory is available to every
thread. signals are shared between threads, file descriptors are
global etc. eCos behaves like one process with multiple threads.

       Andrew

-- 
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] One process with multiple threads??

[Ilija Kocho]

graham_k wrote:
> Sorry to be such a n00b, but can someone please explain WikiPedia's statement
> that "eCos (embedded configurable operating system) is an open source,
> royalty-free, real-time operating system intended for embedded systems and
> applications which need only one process with multiple threads"?
>
> Why only one process? And presumably the thread are what I would think of as
> processes in "normal" terminology?
>   
You can say. More common word is task.
> I guess that what I am asking here is whether this is just a matter of
> semantics (what's a process? what's a thread?) or if there are some
> technical restrictions ...
>   
Sometimes it is, depends on OS' documentation terminology, traditionally 
it all used to be processes.
Processes are supposed to be have their own address space and are 
usually isolated (by means of MMU). On the other hand, threads share 
common address space. Modern GP OSes such (Linux, etc) implement both - 
a process can consist of more threads.

With this respect, since all eCos tasks share common address space they 
are considered threads.

> Thank you very much in advance for any clarification.
>
>   


-- 
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] One process with multiple threads??

[graham_k]

Thanks to both of you, that makes it perfectly clear.

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.

In practise, we just tend to test to death & hope that this sort of thing
never happens ;-)  Does ECOS have any hooks for user coded recovery action
in such an eventuality? Jsut curios, I am sure that it does & I will find
out when I rtfm.

I'm looking generally at Finite State Machines, mainly 'comms, and ECOS
looks like a great o/s.



Andrew Lunn-2 wrote:
> 
> On Wed, Apr 01, 2009 at 10:44:42PM -0700, graham_k wrote:
>> 
>> Sorry to be such a n00b, but can someone please explain WikiPedia's
>> statement
>> that "eCos (embedded configurable operating system) is an open source,
>> royalty-free, real-time operating system intended for embedded systems
>> and
>> applications which need only one process with multiple threads"?
>> 
>> Why only one process? And presumably the thread are what I would think of
>> as
>> processes in "normal" terminology?
>> 
>> I guess that what I am asking here is whether this is just a matter of
>> semantics (what's a process? what's a thread?) or if there are some
>> technical restrictions ...
>> 
>> Thank you very much in advance for any clarification.
> 
> It is using the Unix/POSIX terminology.
> 
> In the unix world, processes are separated from each other. They have
> separate memory space, they have separate signal handlers, file
> descriptor space, sockets etc... If a process gets a segfault, just
> that process dies.
> 
> However a process may have many POSIX threads. Within the process, the
> threads have complete access to all the processes memory, signals,
> file descriptors etc. If a thread gets a sigfault, the whole process
> dies. 
> 
> eCos has no memory protection. All memory is available to every
> thread. signals are shared between threads, file descriptors are
> global etc. eCos behaves like one process with multiple threads.
> 
>        Andrew
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/One-process-with-multiple-threads---tp22841286p22842125.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.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] One process with multiple threads??

[Ross Younger]

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

Re: [ECOS] One process with multiple threads??

[Martin Hansen]

2009/4/2 Ross Younger <wry@ecoscentric.com>:
> 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.
And not less the "one process" model free You of the demand for a MMU
in the processor, and opens the possibility to use a smaller CPU like
the ARM7 series.

MMU Memory Management Unit, is the hardware that makes separate
address spaces possible, this is not pressent in many small devices,
so here you need an OS that can run without.

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