Questions regarding pthread mutex lock/unlock functions in pthread_cond_wait?

[Florian Weimer]

* Noah Goldstein:

> On Thu, May 26, 2022 at 3:09 AM Florian Weimer <fweimer@redhat.com> 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?

Thanks,
Florian