[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAG48ez29cS9KKC_0g_eCxiUsSpg1CjJzt83sBViY0izzf4K5yQ@mail.gmail.com>
Date: Fri, 1 Dec 2023 17:03:25 +0100
From: Jann Horn <jannh@...gle.com>
To: Waiman Long <longman@...hat.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
Jonathan Corbet <corbet@....net>, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org
Subject: Re: [PATCH] locking: Document that mutex_unlock() is non-atomic
On Fri, Dec 1, 2023 at 4:52 PM Waiman Long <longman@...hat.com> wrote:
> On 12/1/23 10:01, Jann Horn wrote:
>> I think this pattern anyway only works when you're only trying to wait
>> for the current holder of the lock, not tasks that are queued up on
>> the lock as waiters - so a task initially holds a stable reference to
>> some object, then acquires the object's lock, then drops the original
>> reference, and then later drops the lock.
>> You can see an example of such mutex usage (which is explicitly legal
>> with userspace POSIX mutexes, but is forbidden with kernel mutexes) at
>> the bottom of the POSIX manpage for pthread_mutex_destroy() at
>> <https://pubs.opengroup.org/onlinepubs/007904875/functions/pthread_mutex_destroy.html>,
>> in the section "Destroying Mutexes".
>
> The POSIX mutex is reference-counted.
I don't understand what you mean by that.
Anyway, I guess this thread of discussion is moot - I'm not suggesting
that kernel mutexes should support this behavior.
Powered by blists - more mailing lists