Re: Questions regarding pthread mutex lock/unlock functions in pthread_cond_wait?

[Noah Goldstein <goldstein.w.n@gmail.com>]

On Thu, May 26, 2022 at 11:17 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * 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.

We have a fair number of tests to check that destroy on a "used" lock
returns EBUSY.

User code might have started to rely on it. Maybe best to keep or you
think still go ahead?

>
> >> > 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
>