From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 3ED811F4B4 for ; Sun, 20 Sep 2020 23:37:15 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1C36C397280C; Sun, 20 Sep 2020 23:37:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1C36C397280C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1600645034; bh=LhcW4cyBbNjnUOXiJTX79w1zWxyeBRdLlVC58A/dtt8=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=KoC+TWJB9sfpQWFaDO4NtDA4ZoII8bH+R4eMZGVOHAD6xc601vne7NMXAg4Wkhhmo wnl8bssMNgS1tGCE0SEmj9qNlRz3oC87MHzeX0qbdDOzmfdCDDPGE+DeHVt36GWMYD JjOK1h/y6aMCDUE0z/GNzesxEbwWsI4EQODABIuE= Received: from mail-ej1-x641.google.com (mail-ej1-x641.google.com [IPv6:2a00:1450:4864:20::641]) by sourceware.org (Postfix) with ESMTPS id 49A633857C61 for ; Sun, 20 Sep 2020 23:37:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 49A633857C61 Received: by mail-ej1-x641.google.com with SMTP id q13so15202599ejo.9 for ; Sun, 20 Sep 2020 16:37:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WEeZ2xHvJt6fz/uX5w9b/04/N76UGoGnmo9fxJ0JCek=; b=MWInBf1M0xuIS5aXhALgu9hlXAu7NYfAS3U1SmhtYUPDHiDfkofjn7XLODXhDgzos6 SXtKFE+ZFnTS/OCHDptF1hzqWKKcG0cVDtrAtgSQt8YbhfCBZvfnz6mgZPEjGBkwAVod eySjR7vY9UOLRU8o8wyFdj1wmaLii3O/e1T2t82Ze24Jb+cqZjpQENC2SBAq1M6DpSjj 5MncPL+qmxOi7IxjXWwpadk0AV4tzPIdt9sc0jpoQoZJQPhZHpCuwFDLpgJs0Shn08a/ HEB6+Gt9jOqizwiCQ6vqa/+Ao3Ip5k+WQhx2JXzXHo25jsfPypY3rCykWs2pBHxTg5lq V5Iw== X-Gm-Message-State: AOAM5327fL393eZ0+tT4KgsUNKIuWJ766RXucaMcOT+CPD9dj8HEYzmS RaOyPpy+LOqSs+ROWcWcF4QY7/rHQ1vV6kBahwX0fQ== X-Google-Smtp-Source: ABdhPJwOW3Dr3/XmJsALbyj2oEriZwVMzeBdjF5bK+4ngsznj6UBG79ySLtn9z7jzMllWTMl8+UcRE4alnvD7+uSpFY= X-Received: by 2002:a17:907:aa9:: with SMTP id bz9mr45809024ejc.421.1600645030041; Sun, 20 Sep 2020 16:37:10 -0700 (PDT) MIME-Version: 1.0 References: <20200920095750.396908-1-vitalybuka@google.com> <20200920120957.852821-1-vitalybuka@google.com> In-Reply-To: Date: Sun, 20 Sep 2020 16:36:32 -0700 Message-ID: Subject: Re: [PATCH] stdlib: Fix data race in __run_exit_handlers To: Paul Pluzhnikov Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Vitaly Buka via Libc-alpha Reply-To: Vitaly Buka Cc: GLIBC Devel Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" Oh, this atomics are not what I thought. So the test reproduced bugs in the test. I tried different approaches and I failed to reproduce the data race. On Sun, 20 Sep 2020 at 14:26, Vitaly Buka wrote: > > > On Sun, 20 Sep 2020 at 13:42, Paul Pluzhnikov > wrote: > >> On Sun, Sep 20, 2020 at 5:10 AM Vitaly Buka via Libc-alpha >> wrote: >> >> > +static void * >> > +threadfunc (void *unused) >> > +{ >> > + for (; done < 1e6;) >> > + { >> > + if (added < done + 100) >> > + { >> > + __cxa_atexit (&atexitcb, (void *)(++added), __dso_handle); >> >> Isn't there a data race on "added" here (in addition to a data race on >> "done")? >> What prevents two threads from observing "added == 100" at the same >> time and adding two calls with value of 101, which would later trigger >> abort() in exitcb()? >> > > They are atomic. Isn't (++added) guarantee to return different values in > all threads? > > >> >> > + /* With default 8MiB Linux stack size, creating 1024 threads can >> cause >> > + VM exhausiton on 32-bit machines. Reduce stack size of each >> thread to >> > + 128KiB for a maximum required VM size of 128MiB. */ >> >> This comment is far removed from the computation of kStacksize (and >> the name violates the naming conventions used here). >> >> I suggest: >> >> size_t stack_size = 128 << 10; /* 128KiB */ >> if (stack_size < PTHREAD_STACK_MIN) stack_size = PTHREAD_STACK_MIN; >> >> Also, I suspect that 32KiB would be more than enough for stack size here. >> >> > + for (i = 0; i < kNumThreads; ++i) >> >> Since kNumThreads isn't used anywhere else, I suggest making it a local: >> >> const int num_threads = 50; >> >> -- >> Paul Pluzhnikov >> >