From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) by sourceware.org (Postfix) with ESMTPS id DE61D385735F for ; Fri, 23 Sep 2022 13:28:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DE61D385735F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-ot1-x336.google.com with SMTP id u6-20020a056830118600b006595e8f9f3fso28412otq.1 for ; Fri, 23 Sep 2022 06:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date; bh=zg7pob3nTUyd62B3i7r1YaYROkqRMZ+syQ+mLbAJDnI=; b=D0YehLbhcYsBCmZmpdWdoPxcl2JmEfs62Ug7MVyYSu9ESe9QZH/bFzX2m7oXaeiP0B JmWQ0mDuJ+rCnuX9FzzMXF0BMiR+It3qH/bYfnX23HIDJIKbXvMRF7ErAtM9OVtbqTNA jQj8r93sdgwfRsyXDs1s46OdfoDeUQwEtyrkWN2R7+ai1RtbyMj/jU8kiiRqP36kpPwo uflOCfxkWeraDykpwEEBUlGGUVhlDXcYQwlD/dof5clMq4A5ZMwE13gxzUtcB2VKlQI+ O9bKwWGcc+WzrwKocy5/fp1B7MOH0zyv2glty8E08HUNkRHjsCxGhpG8he3wQn1+G21l 3OZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=zg7pob3nTUyd62B3i7r1YaYROkqRMZ+syQ+mLbAJDnI=; b=mQOSlk49PCS/iZRYXuxMAh64ttJGI569tVP6Zv8IoJo7+8A8wlH5GXoqE5HV7jkBN7 OPByGq2vSAt1Q8/VxCPanbIrnbENE6qqR5Hfd/16TK7xcD1aaE6S8fjSHy12GSGRZNPm E2V3JOfkWMhAMTE8WDo66zcEVUpw4yQQcDfylgS2Hqm3MiEVuyrhfKyLamQWquPFWPgO wyCXZT7eum78iOM2JUk+UVOIrHq8Xtc0K/U0C0sIbHC/tczhT8uMnsNd3lwyw5eufML3 iAhVUcFegMKeSZmDhFKtCcxw9UMRbKlrzKyo0W6GycAPtx6mcBj2BX0vYQkqn54bncZ5 Yrvw== X-Gm-Message-State: ACrzQf2qfVUnPc/XFm15tKaSQVIRIR/hcMzOI9PyGlQDRaQVhsaM4NQF OrsscYU408v5Tbdee8/Ho6i86w== X-Google-Smtp-Source: AMsMyM4dpo49W2Xg/0fSeGsbkU+SQ6n1N1lQj3gWguuCvbOi+T4144D3k5BI/9FtUxl/84GKvzCqpw== X-Received: by 2002:a05:6830:268c:b0:658:6438:de0c with SMTP id l12-20020a056830268c00b006586438de0cmr4125720otu.230.1663939700077; Fri, 23 Sep 2022 06:28:20 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:c266:202e:f71c:c0e7:6b4e? ([2804:1b3:a7c1:c266:202e:f71c:c0e7:6b4e]) by smtp.gmail.com with ESMTPSA id 43-20020a9d0bae000000b0063711d42df5sm3970832oth.30.2022.09.23.06.28.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Sep 2022 06:28:19 -0700 (PDT) Message-ID: <7ee6df40-c391-8d75-040f-dcf57b7c3609@linaro.org> Date: Fri, 23 Sep 2022 10:28:17 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: [PATCH] Use C11 atomics instead atomic_decrement_and_test Content-Language: en-US To: Wilco Dijkstra , 'GNU C Library' References: From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 22/09/22 10:55, Wilco Dijkstra wrote: > Hi Adhemerval, > >> +  if (atomic_fetch_add_relaxed (&pthread->nr_refs, -1) != 1) >>       return; >>   >>     /* Withdraw this thread from the thread ID lookup table.  */ > >> Ok (and I am not sure why __pthread_create_internal usage does not use atomic at all). > > Yes the non-atomic increment is a bug, an in/decrement could be lost if there is > a data race. Is it still used or could we default to nptl and remove the htl stuff? The htl is used the pthread implementation on Hurd. I am not sure if this support multiprocessor environments, so I will let Hurd developers figure out if they need to fix it. > >> I am not sure if MO is suffice here, shouldn't it synchronize with the update >> from __pthread_create_internal? > > As discussed in my previous mail, __pthread_total and __nptl_nthreads are simple > counters that decide when to call exit for the last thread. Ack. > >> Ok, although this code is not used anywhere (neither for testing). Maybe it would be better >> to just remove it. > > Yes, it looks like it was added 20 years ago as some kind of internal benchmark - I'll remove it > in the commit. Ok. > > Cheers, > Wilco Patch looks good me then. Reviewed-by: Adhemerval Zanella