On Thu, Apr 23, 2015 at 3:09 PM, Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
>
> ----- Gedare Bloom <ged...@rtems.org> schrieb:
>> On Thu, Apr 23, 2015 at 9:30 AM, Sebastian Huber
>> <sebastian.hu...@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()).
>
OK thanks this explanation would be useful somewhere, maybe just to
clarify the commit message a little bit more.
Gedare
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
