From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3934 invoked by alias); 5 Oct 2017 23:05:20 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 3921 invoked by uid 89); 5 Oct 2017 23:05:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=Hx-languages-length:1247, freedom, our X-HELO: mail-qk0-f175.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=VQyO0WPPqjT5WepaRIySjxj3GaxPPlvxAC3RLR0RHyo=; b=XyK7IIqj5toPvoKLVhj8rgTiCJjl/kywIFwvzxfkBpvpqlJ22zk46yf1AzCtazD1+2 4pIl+43ciFL8UEJhRqr4hrkLCOMJ5YN6lh/KGF2yzD57diH1XsHlkZ23qDB907a/hm+d Rx5Ze6uJR1N74XHf0Gomh+jngPcIG6qXPBiq6wPXIoGu76S6jFvL60QGhDV90oUMvpEJ BNYSFg5O7x5qxwk5zrx5koB89wxQMzIBW+zN1ssUNNjyqC91n1KoLacuN2xQFqR/2kgp QJ1rRYDuSBylg9y15T1fRTImhSn0vPhEVSrUYrFmFkNy3XfCKigXLSKzBe9dRN6WR7iu d5bA== X-Gm-Message-State: AMCzsaWbLXtzklnqz4top8DmPqfOdlZ/1RUKnrUevBJXa59C0Rd70VBK oGaFX/us0Bbj+DYNiG+JOX8jKD+H2Bo= X-Google-Smtp-Source: AOwi7QCo4HAhwcOAXw3Mu2H25Ew8DMH2wtNVObH2CleTxgTFsKW871tuGSB9YTZc7rwngYHZxTBHxA== X-Received: by 10.55.36.74 with SMTP id w71mr32796223qkg.260.1507244717346; Thu, 05 Oct 2017 16:05:17 -0700 (PDT) Subject: Re: [PATCH v2] Fix double-checked locking in __gconv_get_path and __gconv_read_conf [BZ #22062] To: Florian Weimer , Arjun Shankar , libc-alpha@sourceware.org References: <20171002143148.GA41930@aloka.lostca.se> <940c9be0-37ae-ebf7-1013-e6e6a4991028@redhat.com> From: Carlos O'Donell Message-ID: <08eed690-d5eb-ce13-0c61-15a93e4bc8a7@redhat.com> Date: Thu, 05 Oct 2017 23:05:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-10/txt/msg00306.txt.bz2 On 10/05/2017 03:20 PM, Florian Weimer wrote: > On 10/05/2017 10:22 PM, Carlos O'Donell wrote: >> Is there any reason we need this atomic load? > > Based on the context, it's not clear to which load you are referring. > > Florian My apologies, clipped, to show context: > + if (gconv_path_elem_local == NULL) > + { > + __gconv_get_path (); Multiple reads by threads are safe. In this case we can have multiple threads here, but all writes to __gconv_path_elem are complete. All we are doing is having multiple readers, which is not a data race. Is there any reason we need this atomic load? > + gconv_path_elem_local = atomic_load_relaxed (&__gconv_path_elem); ^^^^^^^^^^^^^^^^^^^ In the exiting free_mem case I can see the argument for a detached thread doing the initialization while free_mem is called, and it should be thread safe to call exit and these functions, avoiding the data race, but perhaps still crashing for other reasons. We are being consistent in our use of atomic accesses to provide data race freedom. But in this case there is no race. Is it just belt-and-suspenders? If so, we should comment on that. -- Cheers, Carlos.