This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] [gomp] Recycle non-nested team if possible
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Sebastian Huber <sebastian dot huber at embedded-brains dot de>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 14 Jul 2015 12:44:37 +0200
- Subject: Re: [PATCH] [gomp] Recycle non-nested team if possible
- Authentication-results: sourceware.org; auth=none
- References: <1436786144-8625-1-git-send-email-sebastian dot huber at embedded-brains dot de> <20150713141721 dot GS1788 at tucnak dot redhat dot com> <55A3CC4A dot 2000000 at embedded-brains dot de> <55A4B491 dot 7000706 at embedded-brains dot de> <55A4B58D dot 6010209 at embedded-brains dot de> <20150714071901 dot GZ1788 at tucnak dot redhat dot com> <55A4D632 dot 2060102 at embedded-brains dot de>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Jul 14, 2015 at 11:28:18AM +0200, Sebastian Huber wrote:
> If I destroy the barrier of the last team, and then initialize it later in
> gomp_new_team()
>
> +static inline struct gomp_team *
> +get_last_team (unsigned nthreads)
> +{
> + struct gomp_thread *thr = gomp_thread ();
> + if (thr->ts.team == NULL)
> + {
> + struct gomp_thread_pool *pool = thr->thread_pool;
> + if (pool != NULL)
> + {
> + struct gomp_team *last_team = pool->last_team;
> + if (last_team != NULL && last_team->nthreads == nthreads)
> + {
> + pool->last_team = NULL;
> + gomp_barrier_destroy (&last_team->barrier);
> + return last_team;
> + }
> + }
> + }
> + return NULL;
> +}
>
> then I get test suite failures. Is it safe to destroy the team barrier here
> or do we circumvent the last team mechanism which is supposed to delay the
> destruction?
Then you indeed supposedly hit the reason why last_team exists.
Thus, if not reinitializing the team barrier works even with
--disable-linux-futex configured libgomp, I guess it is ok not to
destroy it and reinit it again.
Jakub