From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5990 invoked from network); 21 Apr 2022 19:09:46 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 21 Apr 2022 19:09:46 -0000 Received: (qmail 3582 invoked by uid 550); 21 Apr 2022 19:09:44 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 3547 invoked from network); 21 Apr 2022 19:09:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+MzVwyKtVzvWpt8ePjvkw9FdMCF7W7KchGivL4iqPpg=; b=PR5/YhsiIR/PzQV//rJmed1MWxXp5Bb2mhsbcOTfC//ReXJiyyFpo98WfWQK7Q/BlL UnirLeTEs1uPFIJcLn0zy2ddffm6qs+pTYZzRE7YH+SlNagdxWQa/ctjLkb01QhkNO23 OdzmX7ZvFoPs8AKdkcjadxooL/VETc0mtvETtvNAoXtYbC/uM8vKr02u6vsn047+zBUp FO9RzgpQeP4Iu4x5yxPXqGaPixc+gWFYTXRcgQrpsqcIp2+UmoBK3jfsx8dO4qczgsZY x3b3hnwpZEZS/AH+0DC0xQGsUOOMOYBI45weFna3PIEniUV4af/GmtAhj9EmwkM742QP EpPg== 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=+MzVwyKtVzvWpt8ePjvkw9FdMCF7W7KchGivL4iqPpg=; b=gAkDIDJA2GIXhElOI3Xo5ca7GKTuUocEXZVIah/pSWmEGrlRtjBfe3wk18O3DM1u7c 1Hfb0TGWW8P+yvc3xpwWApcTT/e/55DdsM5rpNzgn4uTvAOoU+R2k+3jR7EfEjDKQONQ Jz9/A15By1cp7YIhOCfoRPors8tqrw3s40oc7wRamYMHMHBWmWU2eqTpDWkwAkTbIMKJ 3/yDyp1DxAtrMhMAbUF8kOi5fraEV0Xsg7/GrcYVSwVtEV0RhTimNWiy+VyNwgOhEsM1 JnZ1qXnC5wi6YilwfEuqrBtAkzkLSgR3ueSB30M57Dd+pIFPW9E/M/MomsQCAkGTn8A/ pbxg== X-Gm-Message-State: AOAM5320U36r/WbwStzDTPSd9FwIhNI+bk7s3gD47xYLUsPwjDwetfwj Hp/cHsIXu42VhJGnkBBXwzKl6K0fiO2EnCWJVb4= X-Google-Smtp-Source: ABdhPJwtM6MG6hEtk7PdAd3DHMeCJEycgoZR/Y+OCE5ON4LdL/nJhnpYSewg14VI01nwxjJ+TLuAn3o/F5CYd6np8NA= X-Received: by 2002:a1f:9e45:0:b0:345:a7eb:e774 with SMTP id h66-20020a1f9e45000000b00345a7ebe774mr419407vke.5.1650568171358; Thu, 21 Apr 2022 12:09:31 -0700 (PDT) MIME-Version: 1.0 References: <20220420235617.GE7074@brightrain.aerifal.cx> <20220421122512.GF7074@brightrain.aerifal.cx> In-Reply-To: <20220421122512.GF7074@brightrain.aerifal.cx> From: Leonid Shamis Date: Thu, 21 Apr 2022 12:09:20 -0700 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000880de705dd2ed942" Subject: Re: [musl] robust list not issuing FUTEX_WAKE --000000000000880de705dd2ed942 Content-Type: text/plain; charset="UTF-8" Thank you Rich. I misunderstood what was done by the kernel and what was done by the library. I assumed the waiters bit was just for the library and assumed the FUTEX_OWNER_DIED was a flag, not value. To clarify my use case and slightly correct the XY problem, I'm trying to build an extended mutex using either a combination of musl mutexes and musl condition variables, or futexes. My extended mutex is a "deadman switch" of sorts that tracks lifetime of on-device services. It doesn't need to be super performant, since services don't come up and down too frequently. My mutex is similar to a robust process-shared mutex. It supports standard functionality: lock, trylock, timedlock, unlock It supports waiting for the mutex to lock without locking: wait_locked, timedwait_locked It supports waiting for the mutex to unlock: wait_unlocked, timedwait_unlocked (wait_locked returns a unique token that is passed to wait_unlocked to ensure the same service is tracked) And the most annoying requirement is that my mutex must be cancelable. I previously tried making the lock function use a condition variable in order for it to be cancelable, but I couldn't find a way to wake it when the owning process dies. Now, I'm exploring using futex directly. Suggestions for how to write cancelable mutex would be much appreciated :) Thanks again! On Thu, Apr 21, 2022 at 5:25 AM Rich Felker wrote: > > On Wed, Apr 20, 2022 at 07:56:17PM -0400, Rich Felker wrote: > > On Wed, Apr 20, 2022 at 04:46:23PM -0700, Leonid Shamis wrote: > > > Hey Musl Folks, > > > > > > I'm trying to understand the futex robust list and it's not quite working > > > how I would expect it to from a reading of the man pages. > > > > > > In a minimal example, I'm getting the futex changed to FUTEX_OWNER_DIED > > > instead of FUTEX_OWNER_DIED|tid and I'm not getting a FUTEX_WAKE event. > > > Any idea why this might be? > > > > > > Happy to share the minimal example. > > > > Can you clarify if you're trying to use robust mutexes under musl or > > roll your own thing using the kernel robust list directly? I don't > > think I'm understanding what you're confused about. If the owner of a > > robust mutex dies, its tid can no longer be in the futex word because > > that tid is immediately available to be assigned to a new task, and > > the next thread trying to lock the mutex would not be able to > > distinguish whether it's owned by a new thread with that tid, or > > available. > > > > So as far as the kernel is concerned, FUTEX_OWNER_DIED is more of a > > value than a flag. It's what the futex word gets set to when the owner > > dies with it held. In musl, we use FUTEX_OWNER_DIED as a flag as well > > for a robust mutex whose old owner died and who has a new owner but > > hasn't yet called pthread_mutex_consistent (in which case it would > > become unrecoverable on unlock). > > Also: you only get the FUTEX_WAIT if the waiters but (bit 31) was set > when the owner died. --000000000000880de705dd2ed942 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Rich. I misunderstood what was done by the kerne= l and what was done by the library. I assumed the waiters bit was just for = the library and assumed the FUTEX_OWNER_DIED was a flag, not value.

= To clarify my use case and slightly correct the XY problem, I'm trying = to build an extended mutex using either a combination of musl mutexes and m= usl condition variables, or futexes.

My extended mutex is a "de= adman switch" of sorts that tracks lifetime of on-device services. It = doesn't need to be super performant, since services don't come up a= nd down too frequently.

My mutex is similar to a robust process-shar= ed mutex.

It supports standard functionality: lock, tryl= ock, timedlock, unlock
It supports waiting for the mutex to lock without= locking: wait_locked, timedwait_locked
It supports waiting for the mute= x to unlock: wait_unlocked, timedwait_unlocked

(wait_locked returns = a unique token that is passed to wait_unlocked to ensure the same service i= s tracked)

And the most annoying requirement is that my mutex must b= e cancelable.

I previously tried making the lock function use a cond= ition variable in order for it to be cancelable, but I couldn't find a = way to wake it when the owning process dies.

Now, I'm exploring = using futex directly.

Suggestions for how to write cancelable mutex = would be much appreciated :)

Thanks again!


On Thu, Apr 21= , 2022 at 5:25 AM Rich Felker <dalias= @libc.org> wrote:
>
> On Wed, Apr 20, 2022 at 07:56:17PM= -0400, Rich Felker wrote:
> > On Wed, Apr 20, 2022 at 04:46:23PM = -0700, Leonid Shamis wrote:
> > > Hey Musl Folks,
> > = >
> > > I'm trying to understand the futex robust list a= nd it's not quite working
> > > how I would expect it to fr= om a reading of the man pages.
> > >
> > > In a min= imal example, I'm getting the futex changed to FUTEX_OWNER_DIED
>= > > instead of FUTEX_OWNER_DIED|tid and I'm not getting a FUTEX_= WAKE event.
> > > Any idea why this might be?
> > >=
> > > Happy to share the minimal example.
> >
>= > Can you clarify if you're trying to use robust mutexes under musl= or
> > roll your own thing using the kernel robust list directly?= I don't
> > think I'm understanding what you're confu= sed about. If the owner of a
> > robust mutex dies, its tid can no= longer be in the futex word because
> > that tid is immediately a= vailable to be assigned to a new task, and
> > the next thread try= ing to lock the mutex would not be able to
> > distinguish whether= it's owned by a new thread with that tid, or
> > available.> >
> > So as far as the kernel is concerned, FUTEX_OWNER_= DIED is more of a
> > value than a flag. It's what the futex w= ord gets set to when the owner
> > dies with it held. In musl, we = use FUTEX_OWNER_DIED as a flag as well
> > for a robust mutex whos= e old owner died and who has a new owner but
> > hasn't yet ca= lled pthread_mutex_consistent (in which case it would
> > become u= nrecoverable on unlock).
>
> Also: you only get the FUTEX_WAIT = if the waiters but (bit 31) was set
> when the owner died.
--000000000000880de705dd2ed942--