[PATCH] score: Fix POSIX thread join

[Sebastian Huber]

----- Gedare Bloom <gedare at rtems.org> schrieb:
> On Thu, Apr 23, 2015 at 9:30 AM, Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
> > A thread join twofold.  One side uses a thread queue and the other not.
> > So we must not use the same state.
> >
> > Update #2035.
> > ---
> >  cpukit/libmisc/monitor/mon-prmisc.c           | 1 +
> >  cpukit/posix/src/pthreadjoin.c                | 2 +-
> >  cpukit/score/include/rtems/score/statesimpl.h | 4 +++-
> >  3 files changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/cpukit/libmisc/monitor/mon-prmisc.c b/cpukit/libmisc/monitor/mon-prmisc.c
> > index ff54d79..f981a4e 100644
> > --- a/cpukit/libmisc/monitor/mon-prmisc.c
> > +++ b/cpukit/libmisc/monitor/mon-prmisc.c
> > @@ -138,6 +138,7 @@ static const rtems_assoc_t rtems_monitor_state_assoc[] = {
> >      { "ZOMBI",  STATES_ZOMBIE, 0 },
> >      { "MIGRA",  STATES_MIGRATING, 0 },
> >      { "RESTA",  STATES_RESTARTING, 0 },
> > +    { "Wjoin",  STATES_WAITING_FOR_JOIN, 0 },
> Does the order matter here, or can the state be located next to "Wjatx"?
> 

Ok.

> >      { 0, 0, 0 },
> >  };
> >
> > diff --git a/cpukit/posix/src/pthreadjoin.c b/cpukit/posix/src/pthreadjoin.c
> > index 99cc4d3..e2b1664 100644
> > --- a/cpukit/posix/src/pthreadjoin.c
> > +++ b/cpukit/posix/src/pthreadjoin.c
> > @@ -71,7 +71,7 @@ on_EINTR:
> >          _Thread_queue_Enqueue(
> >            &api->Join_List,
> >            executing,
> > -          STATES_WAITING_FOR_JOIN_AT_EXIT | STATES_INTERRUPTIBLE_BY_SIGNAL,
> > +          STATES_WAITING_FOR_JOIN | STATES_INTERRUPTIBLE_BY_SIGNAL,
> >            WATCHDOG_NO_TIMEOUT
> >          );
> >        }
> > diff --git a/cpukit/score/include/rtems/score/statesimpl.h b/cpukit/score/include/rtems/score/statesimpl.h
> > index 074b352..9f94675 100644
> > --- a/cpukit/score/include/rtems/score/statesimpl.h
> > +++ b/cpukit/score/include/rtems/score/statesimpl.h
> > @@ -84,6 +84,8 @@ extern "C" {
> >  #define STATES_MIGRATING                       0x400000
> >  /** This macro corresponds to a task restarting. */
> >  #define STATES_RESTARTING                      0x800000
> > +/** This macro corresponds to a task waiting for a join. */
> > +#define STATES_WAITING_FOR_JOIN                0x1000000
> >
> >  /** This macro corresponds to a task which is in an interruptible
> >   *  blocking state.
> > @@ -97,7 +99,7 @@ extern "C" {
> >                                   STATES_WAITING_FOR_SEMAPHORE          | \
> >                                   STATES_WAITING_FOR_MUTEX              | \
> >                                   STATES_WAITING_FOR_CONDITION_VARIABLE | \
> > -                                 STATES_WAITING_FOR_JOIN_AT_EXIT       | \
> > +                                 STATES_WAITING_FOR_JOIN               | \
> Is it right to remove WAITING_FOR_JOIN_AT_EXIT here?

Yes, this is the key point of the patch.  The join is twofold.  There is one thread that exists and an arbitrary number of threads that wait for the thread exit (one-to-many relation).  The exitting thread may want to wait for a thread that wants to join its exit (STATES_WAITING_FOR_JOIN_AT_EXIT in _POSIX_Thread_Exit()).  On the other side we need a thread queue for all the threads that wait for the exit (STATES_WAITING_FOR_JOIN in pthread_join()).

> 
> Is it possible to replace all WAITING_FOR_JOIN_AT_EXIT with
> WAITING_FOR_JOIN? Then the enum and bit values can be just renamed.
> 
> >                                   STATES_WAITING_FOR_SIGNAL             | \
> >                                   STATES_WAITING_FOR_BARRIER            | \
> >                                   STATES_WAITING_FOR_BSD_WAKEUP         | \
> > --
> > 1.8.4.5
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.