From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <fweimer@redhat.com>
Received: from us-smtp-delivery-1.mimecast.com
 (us-smtp-delivery-1.mimecast.com [207.211.31.120])
 by sourceware.org (Postfix) with ESMTP id E7A8E388C011
 for <libc-alpha@sourceware.org>; Mon, 29 Jun 2020 14:20:17 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E7A8E388C011
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-41-tHEn2nncN0-ewSEK8f3_4g-1; Mon, 29 Jun 2020 10:19:45 -0400
X-MC-Unique: tHEn2nncN0-ewSEK8f3_4g-1
Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com
 [10.5.11.22])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 843B0107ACF5;
 Mon, 29 Jun 2020 14:16:41 +0000 (UTC)
Received: from oldenburg2.str.redhat.com (ovpn-112-196.ams2.redhat.com
 [10.36.112.196])
 by smtp.corp.redhat.com (Postfix) with ESMTPS id D8D6F1002397;
 Mon, 29 Jun 2020 14:16:40 +0000 (UTC)
From: Florian Weimer <fweimer@redhat.com>
To: Andreas Schwab <schwab@suse.de>
Cc: Florian Weimer via Libc-alpha <libc-alpha@sourceware.org>
Subject: Re: [PATCH] nscd: bump GC cycle during cache pruning (bug 26130)
References: <mvmeeqd3hrd.fsf@suse.de>
 <877dvq2s6a.fsf@oldenburg2.str.redhat.com> <mvmftaenori.fsf@suse.de>
 <871rlyywoz.fsf@oldenburg2.str.redhat.com> <87eepyyndz.fsf@igel.home>
Date: Mon, 29 Jun 2020 16:16:39 +0200
In-Reply-To: <87eepyyndz.fsf@igel.home> (Andreas Schwab's message of "Mon, 29
 Jun 2020 16:09:28 +0200")
Message-ID: <871rlyx8hk.fsf@oldenburg2.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain
X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH,
 DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE,
 RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS,
 TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: libc-alpha@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org>
List-Unsubscribe: <http://sourceware.org/mailman/options/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help>
List-Subscribe: <http://sourceware.org/mailman/listinfo/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2020 14:20:31 -0000

* Andreas Schwab:

> On Jun 29 2020, Florian Weimer via Libc-alpha wrote:
>
>> * Andreas Schwab:
>>
>>> On Jun 29 2020, Florian Weimer wrote:
>>>
>>>> I think this needs barriers after and before the increments.
>>>
>>> Why doesn't gc need those barriers?
>>
>> I think it needs them as well.  I thought we had them there. 8-(
>
> Should they use atomic_increment?

Yes, that as well.  I don't know if the legacy atomic_increment function
implies a barrier.  I think we need the equivalent of __atomic_fetch_add
(or __atomic_add_fetch) with __ATOMIC_ACQ_REL, and our <atomic.h> does
not have this, and we are not supposed to use the compiler built-ins.

atomic_fetch_add_relaxed together with atomic_full_barrier should work,
though.

Thanks,
Florian