Re: [PATCH] locking: Document that mutex_unlock() is non-atomic

[Jann Horn]

On Fri, Dec 1, 2023 at 4:52 PM Waiman Long <longman@xxxxxxxxxx> 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.