[ECOS] "Threads on ecos" confirmation needed...

[Dirk Broer]

As best I can tell.

We use POSIX interface to threads.  We join on the threads all the time.  At
some points of execution, I can say we are creating and destroying 5 threads
a second, potentially over an extended period of time with no ill effects.
All threads are joined, but we don't do much in the way of cleanup so its
not a tough test.  Threads are encapsulated in a C++ object, using static
methods for callbacks.

Lessons learned
1) Consider ECOS threads directly if you can.  POSIX threads aren't named
and makes debugging easier.
2) We need to clean up our thread per task algorithm.  (yeah, sure, when we
have time).

            __  __      ___   ________  ___      __  ___      ___
Dirk Broer / ||/ ||    /_ || /__  __// /__ \\   /// /__ \\   / __\\
          //||//|||   ///|||   ///    ///_///  __  /// |||  ///_
         ///| //|||  /___ ||  ///    /__  //  /// ///      /__ ||
        /// |// ||| ///  ||| ///    /// |||  /// ///__/// ____///
       ///      |||///   |||///    ///  ||| ///  |____// /____//
Software Engineer


#include <standard_disclaimer>
#include <funny_quote>

-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of Ivan Horvat
Sent: Friday, January 30, 2004 1:09 PM
To: ecos-discuss@sources.redhat.com
Subject: [ECOS] "Threads on ecos" confirmation needed...


Hi.

I have a question/doubt regarding threads. If I got the picture correctly,
there's no way to create a thread such that the thread-object storage is
automatically/dynamically allocated instead of supplied by "user" (or the
thread creator). This creates the problems, as exiting thread cannot clean
up its resources because:
  * If the thread-object storage is freed (or in c++ deconstructed) and then
    either cyg_thread_exit() or (directly) thread->exit() is called,
    the scheduler will crash soon after the "exit" call
  * if the thread calls "exit" routine, then it doesn't have a chance to
    clean up, as *exit() never returns (other thread must do the cleaning)

This causes inefficiencies in pthread implementation because, for example:
  1) The several *detached* threads are created.
  2) All the threads exit. The per-thread keys are destroyed, waiting
     "joiners" are "kicked" via condition variables. But, the stack spaces
     and spaces holding Cyg_Thread objects are still hanging around.
  3) Those unreleased data hangs until the next call to pthread_create(),
     which first reaps all exited threads and cleans after them. There may
     be a lot of zombie data pending, as some threads can have big stacks,
     which is bad for embedded systems.

Can someone please tell me whether my understanding is correct or not?


And, if I got it right, would it be possible for future releases of ecos to
create threads where the kernel itself would allocate/deallocate space for
thread object? Probably, this may have negative impact on RT
performance, but
may be quite useful feature in some cases/applications.


Regards,

Ivan Horvat.





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




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