From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) by sourceware.org (Postfix) with ESMTPS id 43776385380B for ; Mon, 7 Jun 2021 21:53:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 43776385380B Received: by mail-qt1-x82f.google.com with SMTP id s12so13810990qta.3 for ; Mon, 07 Jun 2021 14:53:03 -0700 (PDT) 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=V6d2cBcIMfooTWrHhUK1uWMpCPAJnJl7WEQcbjE8ifA=; b=nOWGYt56Mbv+GO6bICNSALJBI0XXA7d1M9X1ClJWGVz5RUxLd2CPyyj8UkMxnyX4Mh LSTVBOc6fI7nUSfP9D8FKJIXOBlIYR0baHQPM0CNektP/j271F7QArPtErOPkgZ/kBII iFxMbpYOlCRWEIs6Gf+OigsIN/KaPGJN5NPoQIh7ceyP1aFyuJQYDRDK4UhW4P5A4Gb4 cPNQV42lry4D/vFzGklhZ3lbcprQ07AN7TtjY68dH0kwTQsxBkahb8BunkN9svUNHUm3 Y1j6EoGRQLxr1GBLudrV2wPNIfoAc6iklWFodGlqvsvQZ25cDPjkr4rqtkPZr2yDj3zB ZYTQ== X-Gm-Message-State: AOAM531kLTkpqJpGuy0mMyCTVgyO5e48HcxgOWR/vOUo4W4fUulzpPdW TAzxNBkpwyVgdu5GHZIqTEIdF9r7+IqLXQ== X-Google-Smtp-Source: ABdhPJxMabzTCFYtFxS0BYcDcqemBB0yLwy/nWycq0J4AO+3XsIWvKiLqJ5HW1mGBIhnsEKyV9PC3A== X-Received: by 2002:a05:622a:1207:: with SMTP id y7mr15995069qtx.212.1623102782672; Mon, 07 Jun 2021 14:53:02 -0700 (PDT) Received: from [192.168.1.4] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id k6sm9601417qtg.78.2021.06.07.14.53.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Jun 2021 14:53:02 -0700 (PDT) Subject: Re: glibc pthreads and optimized locks To: dumblob , Libc-help References: From: Adhemerval Zanella Message-ID: <44a46000-0b6f-0c9b-54e7-8b9982044028@linaro.org> Date: Mon, 7 Jun 2021 18:53:00 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.5 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 21:53:13 -0000 On 07/06/2021 10:30, dumblob via Libc-help wrote: > Dear glibc experts, > > Does anybody know whether glibc pthreads implement the fast lock > algorithms as https://github.com/AlexeyAB/object_threadsafe does? > > A detailed description of these algorithms is in > https://www.codeproject.com/Articles/1183423/We-Make-a-std-shared-mutex-10-Times-Faster > and some more optimizations in > https://www.codeproject.com/Articles/1183446/Thread-safe-std-map-with-the-speed-of-lock-free-ma > . Btw. I'm aware these articles discuss C++, but the same principles > apply to locks in C. > > I'm asking because pthreads are known to be rather slower in general > and if such optimized variants of locks are not implemented, I'll > propose implementing them in few specific apps which would benefit > from the optimizations (e.g. the main implementation of the V > language). I haven't read al the links in details (the C++ code is specially quite hard to follow...), but as fair as I know the std::shared_ptr (and this alternate implementation) maps more directly to pthread_rwlock_t instead of pthread_mutex_t. Torvald's Riegel optimized back it on glibc 2.25 and there were a couple of fixed back then. He optimized the fast path so a read lock requires only a single atomic addition if the lock is or was previously acquired by other readers while releasing the lock is a single CAS if there are no concurrent writers. The main constraint is the pthread_rwlock_t is it shall follow POSIX requirements regarding memory semantic, from the implementation comment: | /* A reader--writer lock that fulfills the POSIX requirements (but operations | on this lock are not necessarily full barriers, as one may interpret the | POSIX requirement about "synchronizing memory"). All critical sections are | in a total order, writers synchronize with prior writers and readers, and | readers synchronize with prior writers. So I would suggest you to first evaluate the std::shared_ptr and this 'fast lock algorithms' against pthread_rwlock_t. The pthread_rwlock_t does block by calling futex, so it is not really lock-free. You might try to provide a pthread_rwlock_t which lock-free, but then you will need to check if this provides *all* the POSIX requirements. I am not sure this would be possible without something really clever and somewhat hacky as rseq support. Otherwise, I don't think glibc is the correct place to support alternate locking mechanism (you have multiple specialized libraries such as the one you referred that I think is a better way to provide it). One TODO you might want to explore is the use o Hardware Transaction Memory on pthread_rwlock_t. It was previously supported, but with Torvald newer implementation it was not added back.