From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x112e.google.com (mail-yw1-x112e.google.com [IPv6:2607:f8b0:4864:20::112e]) by sourceware.org (Postfix) with ESMTPS id E84CC3857C50 for ; Thu, 26 May 2022 16:28:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E84CC3857C50 Received: by mail-yw1-x112e.google.com with SMTP id 00721157ae682-2fee010f509so20783017b3.11 for ; Thu, 26 May 2022 09:28:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1xlSc/8RfjCWSUuyzaLnN+/V4duOyeVAx/OOVdoryKk=; b=Rr39nGPVvX6M0mltDn8vSGt8hsXgCv6ZzADfzOV8xdbre1KtV44GVnUjgmSc/gSQy/ aiRK73ZBgCtZD6giGfqe5LplNo1ZzVyFiSqtpBZTOWDtRKLjAl6PCro8fHpStkt4xZ43 ci8b03zMynaOBRydgKirM6+e1JW18Jn4FRlPxKll1t/m69nfX0gF2k7mbuCMw5bnorgA oRavrXHdc37J+wsNLJOzxZookXbfVvTcgEwuGlNK64ehVhDwdsLx4u9UuOCaAVrugHHw 48m2wT4G82qNi8P1SdQPLL6EUECyBsK5KZs5hfmdNgEp8qsVCXP/aAKJQJDtHTYfDIZj q+4w== X-Gm-Message-State: AOAM532VYzaiUPIuNgbhTs0r0WKJTg67cWulJ7muAR5M6jazoXCTx/MC 2EYmz7JkJiDISWWCeklLe9YXMCeT7k/AmuiPElVdy7bR X-Google-Smtp-Source: ABdhPJzHs64Les3RWkNSAOsfcxfkpF/eud6oJufux2+87hn3/8V7D09NI3k+ckPBjtFP907ogdc/I6jbyTsUNFZrRYo= X-Received: by 2002:a05:690c:d:b0:2d0:e02a:6cda with SMTP id bc13-20020a05690c000d00b002d0e02a6cdamr41398431ywb.192.1653582517364; Thu, 26 May 2022 09:28:37 -0700 (PDT) MIME-Version: 1.0 References: <87y1yoaf5q.fsf@oldenburg.str.redhat.com> <87k0a89skp.fsf@oldenburg.str.redhat.com> In-Reply-To: <87k0a89skp.fsf@oldenburg.str.redhat.com> From: Noah Goldstein Date: Thu, 26 May 2022 11:28:26 -0500 Message-ID: Subject: Re: Questions regarding pthread mutex lock/unlock functions in pthread_cond_wait? To: Florian Weimer Cc: Noah Goldstein via Libc-alpha Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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, 26 May 2022 16:28:39 -0000 On Thu, May 26, 2022 at 11:17 AM Florian Weimer wrote: > > * Noah Goldstein: > > > On Thu, May 26, 2022 at 3:09 AM Florian Weimer wrote: > >> > >> * Noah Goldstein via Libc-alpha: > >> > >> > 1) Do we need `__pthread_mutex_unlock_usercnt`? > >> > >> POSIX says: > >> > >> | Attempting to destroy a locked mutex, or a mutex that another thread > >> | is attempting to lock, or a mutex that is being used in a > >> | pthread_cond_timedwait() or pthread_cond_wait() call by another > >> | thread, results in undefined behavior. > >> > >> This does not change for PTHREAD_MUTEX_ERRORCHECK mutexes, so I think we > >> can remove usercnt. > > > > Open to a patch removing the `__pthread_mutex_unlock_usercnt` > > function? > > And for making that field unused, yes. > > >> > 2) Are people in favor of making it so that > >> > `__pthread_mutex_unlock_usercnt` / `pthread_mutex_cond_lock` go > >> > through the PLT so that researchers trying to replace `pthread_mutex` > >> > in applications rely solely on LD_PRELOAD? > >> > >> Which functions do you mean exactly? > >> > >> I think most internal locks are directly implemented on top of futexes, > >> so I don't think this would make much of a difference. > > > > Can we make it so that > > `__pthread_mutex_unlock_usercnt` and `__pthread_mutex_cond_lock` > > used internally by `pthread_cond_{timed}wait` go through the PLT so > > that using LD_PRELOAD to entirely replace pthread_mutex in an application > > is feasible. Think this would be pretty useful to lock researchers / people > > that want to roll custom locks that are ABI compatible with > > pthread_mutex/PTHREAD_MUTEX_INITIALIZER. > > Why can't they interpose the condition variable implementation as well? Either work, but obviously easier to just do mutex. Think less interest/performance is focussed on condition variables. Is your feeling since it's doable now with a little extra work is not worth the perf hit for normal users? > > Thanks, > Florian >