Threads Vs Forks in Embedded Environment - Embedded

This is a discussion on Threads Vs Forks in Embedded Environment - Embedded ; 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 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Threads Vs Forks in Embedded Environment

  1. Threads Vs Forks in Embedded Environment

    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.


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


  3. Re: Threads Vs Forks in Embedded Environment

    >... threads or forks ...

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



  4. Re: Threads Vs Forks in Embedded Environment

    Abhishek wrote:

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


    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?

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


    Not much. Have you measured?

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


    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


  5. Re: Threads Vs Forks in Embedded Environment

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


    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