From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21409 invoked by alias); 16 Oct 2014 15:52:34 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 21393 invoked by uid 89); 16 Oct 2014 15:52:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 16 Oct 2014 15:52:32 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9GFqUwh010904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 16 Oct 2014 11:52:30 -0400 Received: from tucnak.zalov.cz (ovpn-116-116.ams2.redhat.com [10.36.116.116]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9GFqSRt031125 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Thu, 16 Oct 2014 11:52:30 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id s9GFqRkO006378; Thu, 16 Oct 2014 17:52:27 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id s9GFqPtL003508; Thu, 16 Oct 2014 17:52:25 +0200 Date: Thu, 16 Oct 2014 16:17:00 -0000 From: Jakub Jelinek To: Nathaniel Smith Cc: gcc-patches@gcc.gnu.org Subject: Re: ping x 7: [PATCH] [libgomp] make it possible to use OMP on both sides of a fork Message-ID: <20141016155225.GK10376@tucnak.redhat.com> Reply-To: Jakub Jelinek References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg01585.txt.bz2 On Mon, Oct 13, 2014 at 10:16:19PM +0100, Nathaniel Smith wrote: > Got total silence the last 4 times I posted this, and users have been > bugging me about it offline, so trying again. > > This patch fixes a showstopper problem preventing the transparent use > of OpenMP in scientific libraries, esp. with Python. Specifically, it > is currently not possible to use GNU OpenMP -- even in a limited, > temporary manner -- in any program that uses (or might use) fork() for > parallelism, even if the fork() and the use of OpenMP occur at totally > different times. This limitation is unique to GNU OpenMP -- every > competing OpenMP implementation already contains something like this > patch. While technically not fully POSIX-compliant (because POSIX > gives much much weaker guarantees around fork() than any real Unix), > the approach used in this patch (a) performs only POSIX-compliant > operations when the host program is itself fully POSIX-compliant, and > (b) actually works perfectly reliably in practice on all commonly used > platforms I'm aware of. 1) gomp_we_are_forked in your patch will attempt to free the pool of the thread that encounters it, which is racy; consider a program after fork calling pthread_create several times, each thread thusly created then ~ at the same time doing #pragma omp parallel and the initial thread too. You really should clean up the pool data structure only in the initial thread and nowhere else; for native TLS (non-emulated, IE model) the best would be to have a flag in the gomp_thread_pool structure, struct gomp_thread *thr = gomp_thread (); if (thr && thr->thread_pool) thr->thread_pool->after_fork = true; should in that case be safe in the atfork child handler. For !HAVE_TLS or emulated TLS not sure if it is completely safe, it would call pthread_getspecific. Perhaps just don't register atfork handler on those targets at all? 2) can you explain why are you removing the cleanups from gomp_free_pool_helper ? 3) you can call pthread_atfork many times (once for each pthread that creates a thread pool), that is undesirable, you want to do that only if the initial thread creates thread pool 4) the testcase is clearly not portable enough, should be probably limited to *-*-linux* only, fork etc. will likely not work on many targets. In any case, even with the patch, are you aware that you'll leak megabytes of thread stacks etc.? Jakub