This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
Re: Creating workers threads dynamically
- To: ecos-discuss at sourceware dot cygnus dot com
- Subject: Re: [ECOS] Creating workers threads dynamically
- From: Nick Garnett <nickg at cygnus dot co dot uk>
- Date: 16 May 2000 15:22:17 +0100
- Newsgroups: cygnus.sourceware.ecos.d
- Organization: Cygnus Solutions, a Red Hat company (Cambridge, UK)
- References: <20000516132118.3492.qmail@hotmail.com>
"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