This is the mail archive of the ecos-discuss@sourceware.cygnus.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Creating workers threads dynamically


"Rosimildo daSilva" <rosimildo@hotmail.com> writes:

> Hi,
> 
> Sorry to be posting this again, but I posted it a while back and got no 
> answers.
> 
> I have a question regarding a thread management, specifically killing itself 
> or exiting. The documentation states that exiting a thread
> just suspend it. Looking at the code, I saw that it suspend the
> thread and goes to an infinite loop.
> 
> I'd like to create workers threads dynamic as we need them, and
> when they have completed their tasks, they should kill themselves.
> 
> Question:
> 
> How do I do that ?
> 
> or more specifically,
> 
> is there an alternative "design pattern" for such a problem ?
> 

There is no mechanism in eCos for a thread to delete itself. This is
because dealing with the case where the currently running thread has
destroyed its own data structures could become very complex and is
very prone to being broken. Instead, we expect another thread to call
cyg_thread_delete() on an exited thread to finish off its destruction.


I can think of at least three alternative ways of implementing what you
want to do:

1. The simplest is to not exit your worker threads but to simply halt
   them on a mailbox when they are idle. When you want a thread to do
   something you send a message to the mailbox indicating the task to
   be done and the first worker thread will simply wake up and do it.

2. Have a "reaper" thread that waits on a mailbox. When a worker
   thread is about to exit it posts it handle to the mailbox and calls
   cyg_thread_exit(). The reaper simply wakes up and calls
   cyg_thread_delete() on the handle it receives.

3. Allow each thread to call cyg_thread_exit() when it is
   finished. When a new worker is required, call cyg_thread_resume()
   on an exited thread, and allow it to find out what it is meant to
   do from some static variables.

There are lots of alternative variants of these basic models - I would
prefer option 1 as being the cleanest of the three.

-- 
Nick Garnett
Cygnus Solutions, a Red Hat Company
Cambridge, UK

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]