Threads Vs Forks in Embedded Environment

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi group,

i am doing a project at motorola. i have to clone the client side
mobile phone software update engine.what is better suited for an
embedded environment......threads or forks:

Threads:

Threads require support libraries, so extra space is required in flash
memory.

Updation of libraries may also be required so this may increase the
installation time.

Though threads share resources, in our case the sharing is not
substantial.

Forks:

Forks may have increased RAM  requirement but it depends upon number of
forks . Each fork has its own copy of all the segments of the update
engine.

Can anyone provide me with a comparison of advantages and disadvantages
of threads and forks for embedded environment.


Re: Threads Vs Forks in Embedded Environment
OS is embedded  Linux. The platform is based on a dual core
architecture having an ARM11 core (Application Processor, AP) that
handles all the application level functionalities and a Star Core DSP
processor ( Base band Processor, BP), which handles all the modem
functions. OTASU supports Jffs2, cramfs file system. other products
supports MCU (MCORE) also


Re: Threads Vs Forks in Embedded Environment
Quoted text here. Click to load it

I suppose by "threads" you mean using the "Posix thread library" and by
"fork" you mean using standard processes ?

Another alternative is using clone(), or another api call <I don't
remember the name at the moment>, that additionally e.g. can define the
stack pointer of the thread created. These allow for setting flags on
what should be shared between the threads (CLONE_VM, CLONE_FS,
CLONE_FILES, CLONE_SIGHAND, CLONE_PID). I suppose the libraries uses
these to create threads.

I suppose this is depending on the Kernel version, too.

Of course inter thread communication can be easier than inter process
communication, as you can use shared memory objects, but additional care
must be taken to use thread save functions wherever necessary.

With Kernel 2.6, I suppose the new thread model offers more advantages
over using processes than there were with Kernel 2.4.

-Michael



Re: Threads Vs Forks in Embedded Environment

Quoted text here. Click to load it

In Linux, threads are processes.
fork() creates processes.

So they are essential the same.

Threads share a common data space. This is not significant in your
application, so where is the difference?

Quoted text here. Click to load it

Not much. Have you measured?

Quoted text here. Click to load it

If you have a MMU, the memory consumption of a process maybe lower than you
think because of the copy-on-write semantics.

regards
Wolfgang


Re: Threads Vs Forks in Embedded Environment
Quoted text here. Click to load it

Not true. (1) Kernel 2.6 does have a kernel representation of user land
threads and (2) AFAIK, there are thread libraries that don't use the OS
at all to create the threads but do it completely in user land. Here the
Kernel does not know about the threads. (I suppose this is what the OP
had in mind.)

-Michael

Site Timeline