From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2b.google.com (mail-oa1-x2b.google.com [IPv6:2001:4860:4864:20::2b]) by sourceware.org (Postfix) with ESMTPS id 286E8385742C for ; Thu, 28 Apr 2022 17:15:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 286E8385742C Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-deb9295679so5790121fac.6 for ; Thu, 28 Apr 2022 10:15:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=qkX+h3UQyBgv26FAzrqA7gKeod1fsJ8OLsz85r6yXIo=; b=WxMzJhYzIo4u1WT/rumsqrQypKiU9L77YNOp/iXONkAy4tmzf4uTtWZO2s2OBppO7g JFiAl9im//37bIoXY2pxurn+qeARO5UbhPjy/L5/OwYZDqf8gM9lnuL2lzytj0EHav9F QeZ+kTl3rF6Rq0T2QlrTSeUjU2NLUpO0UR9PfZLVi8GrURbqJ4kSOM5TPsPTh/K3GQl3 AQqxHCXyLhC/51WEvem40Ba2C+wBoHnT5a4fhUpr7I6R9L4H2blqivMj3ZZ+XiStQ5IF 7LR1Esg/pzQ2oVa5T36eOKN89DO6AFzFr84j/oDkbRoss1SZzMdceviCRvGtmItUjTmg 1YLw== X-Gm-Message-State: AOAM530EFL2delLeFA2t0fr4kdhd/SJ+tnc6hhzjm9Ns4gVy+7WuRSTa B7RdMFwDXynHFyT2uTxc2ZSAvt4xdOqOhA== X-Google-Smtp-Source: ABdhPJzXMzzuLdkm5patF3Fk/pF1d5Stf6jOzFNmFLtcIjTOHueiTOQlZ0VlW5zI2qzudTWBjjEvnw== X-Received: by 2002:a05:6870:c1cd:b0:e6:757f:9a04 with SMTP id i13-20020a056870c1cd00b000e6757f9a04mr14413134oad.265.1651166100127; Thu, 28 Apr 2022 10:15:00 -0700 (PDT) Received: from ?IPV6:2804:431:c7ca:4214:4f75:969e:be61:8b2? ([2804:431:c7ca:4214:4f75:969e:be61:8b2]) by smtp.gmail.com with ESMTPSA id e59-20020a9d2ac1000000b00605ea349e11sm172291otb.74.2022.04.28.10.14.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 Apr 2022 10:14:59 -0700 (PDT) Message-ID: <4afb1d62-452e-44b5-2f26-bb44869b1016@linaro.org> Date: Thu, 28 Apr 2022 14:14:57 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH v2 3/4] Move libio lock single-thread optimization to generic libc-lock (BZ #27842) Content-Language: en-US To: Florian Weimer Cc: Adhemerval Zanella via Libc-alpha References: <20220426191523.833171-1-adhemerval.zanella@linaro.org> <20220426191523.833171-4-adhemerval.zanella@linaro.org> <87k0bahcwh.fsf@oldenburg.str.redhat.com> <40a536b8-32ac-51e3-0ac4-bc3d189c0711@linaro.org> <29e0538f-7f80-5e5b-9090-38b29c8fa23a@linaro.org> <87a6c587va.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella In-Reply-To: <87a6c587va.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Thu, 28 Apr 2022 17:15:04 -0000 On 28/04/2022 13:56, Florian Weimer wrote: > * Adhemerval Zanella: > >>>>> (NAME).owner = NULL; \ >>>>> - lll_unlock ((NAME).lock, LLL_PRIVATE); \ >>>>> + if (!SINGLE_THREAD_P) \ >>>>> + lll_unlock ((NAME).lock, LLL_PRIVATE); \ >>>>> } \ >>>>> } while (0) >>>>> #else >>>> >>>> I don't think this is correct if threads are created in the lock region. >>> >>> I was not sure about this one and I think we the main issue in fact there is >>> we can't use the single-thread optimization on unlock. Maybe a better option >>> would to use a different scheme as proposed by >>> https://hal.inria.fr/hal-01236734/document, where we can embedded lock and >>> cnt in only one variable (as the lll_lock already does). >> >> Don't 99f841c441feeaa9a3d97fd91bb3d6ec8073c982 have the issue for pthread_mutex_lock ? > > No, that optimization follows our documented guidance, namely: > > | Most applications should perform the same actions whether or not > | @code{__libc_single_threaded} is true, except with less > | synchronization. If this rule is followed, a process that > | subsequently becomes multi-threaded is already in a consistent state. > So I wonder if /* Lock the recursive named lock variable. */ #define __libc_lock_lock_recursive(NAME) \ do { \ void *self = THREAD_SELF; \ if ((NAME).owner != self) \ { \ if (SINGLE_THREAD_P) \ (NAME).lock = 1; \ else \ lll_lock ((NAME).lock, LLL_PRIVATE); \ (NAME).owner = self; \ } \ ++(NAME).cnt; \ } while (0) /* Unlock the recursive named lock variable. */ /* We do no error checking here. */ #define __libc_lock_unlock_recursive(NAME) \ do { \ if (--(NAME).cnt == 0) \ { \ (NAME).owner = NULL; \ if (SINGLE_THREAD_P) \ (NAME).lock = 0; \ else \ lll_unlock ((NAME).lock, LLL_PRIVATE); \ } \ } while (0) Or if we are bounded to keep the current practice to check for single-thread and skip locks internally. It would be good to consolidate all the internal lock usage and have the single-thread lock optimizations on all locks, not only on pthread_mutex_lock.