Re: Threads Vs Forks in Embedded Environment

abhisheksingh.bits@xxxxxxxxx wrote:
i want to have a specific deifferences between threads and forks in
embedded environment to convince me that i can use threads or
forks....

The major difference is that threads shared their VM while processes
don't. Do you want memory protection between your contexts of
execution, or do you want to share memory?

The advantage of threads, generic and project specific:

The advantage of threads is their lower resource consumption.

Depends on the threading implementation and your specifics. Some
threading implementations (including some on Linux, which you've
indicated you're using) use a management thread of some sort, and so
they can have higher resource consumption in some applications
(especially those with very few threads).

It takes much less CPU time to switch among threads than between
processes, because there's no need to switch address spaces.

Again, depends on the implementation. On modern Linux systems I
certainly wouldn't say it takes "much" less CPU, but that's an
ill-defined word. I believe their are some cases on SMP where
switching between threads can take more time than between independent
processes (CPU cache issues with shared pages).

In addition, because they share address space, threads in a process can
communicate more easily with one another.

What do you mean by easier?

The Disadvantage of threads:

Project Specific:

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

Yes, although you could consider using clone directly if you're not
worried about portability or POSIX compliance. Obviously you need to
use Linux primitives for mutexes,etc as well in that case.

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

I'm not quite sure what this means, presumably an embedded system is
going to come with correct libraries pre-installed--if you're talking
about the developer's side this hardly seems like a major point.

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

That's the biggest factor, to me. If you're not sharing lots of
complex data structures, processes buy you isolation. They're
generally easier to maintain and debug in the long term, although if
you're getting really incestuous with locking and shm things can get
hairy.

Generic:

Programs using threads are harder to write and debug. Not all
programming libraries are designed for use with threads. And not all
legacy applications work well with threaded applications. Some
programming tools also make it harder to design and test threaded code.

In general I agree.

Another problem is concurrency and synchronization complexity.
sharing, locking, deadlock, race conditions come vividly alive in
threads. Processes don't usually have to deal with this, since most
shared data is passed through pipes. Threads can share file
handles,variables, signals, etc. this may lead to error conditions if
not handled properly.

Yes, although multiprocess solutions can get into a lot of these
problems too. At least it's usually a little more explicit where
exactly you're going to run up against locking/synchronization
problems, but if your core problem is one that requires a lot of
coordinated multi-execution then you may see similar problems with
either approach.

Applications executed in a thread environment must be thread-safe. This
means that functions (or the methods in object-oriented applications)
must be reentrant-a function with the same input always returns the
same result, even if other threads concurrently execute the same
function. Accordingly, functions must be programmed in such a way that
they can be executed simultaneously by several threads.

Or you must somehow ensure that they're only called by one thread at a
time.

Thread-related bugs can also be more difficult to find. Threads in a
process can interfere with one another's data.

Yes, the lack of memory protection between threads can mean that a
stray pointer error in one thread manifests itself as weird behavior in
another thread.

Systems like windows and OS/2 are said to have "cheap" threads and
"expensive" processes, while in other OS there is not a big difference.

In _some_ other OSes there is not a big difference.

.

Relevant Pages

  • Re: GoTo in Java
    ... large graphics applications or gaming or simulation software; ... code maintaining shop if you do this.) ... Scripting languages are programming languages; ...
    (comp.lang.cobol)
  • Re: Programming Practices
    ... developing C# applications and programming in general. ... and have developed simple applications to work with Access/SQL databases. ... code into 'layers', you hear about the presentation layer, the data access ... I implemented this with a data access layer, a business logic layer and the ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Why use relational tables in OO (please just take a look inside)
    ... The proper construction of OO applications lies ... programming than that provided by SA/SD/SP. ... > Every paradigm has it's limitations, and OO is not an exception. ... > and a set of not so recently hired employees. ...
    (comp.object)
  • Re: What is .net
    ... software) for installing and running ASP.NET desktop applications and Web ... You just want to learn, and have no experience programming (nothing ... relational database design in general and SQL Server in particular. ... don't ignore the topic of "relational database design" - ...
    (microsoft.public.dotnet.faqs)
  • Re: What is .net
    ... software) for installing and running ASP.NET desktop applications and Web ... You just want to learn, and have no experience programming (nothing ... relational database design in general and SQL Server in particular. ... don't ignore the topic of "relational database design" - ...
    (microsoft.public.dotnet.framework.aspnet.buildingcontrols)