> All the attempts with API extensions didn't go well because glibc did
> not want to change a bit. This starts with a mutex that has a static
> initializer which has to work (I don't remember why the first
> pthread_mutex_lock() could not fail with -ENOMEM but there was
> something) and ends with glibc's struct mutex which is full and has no
> room for additional data storage.
Yes, we have binary compatibility constraints that prevents us to simply
broken old binaries. This is quite true for static initialization,
which imposes even harder constraints, different than the pthread_mutex_t
size where we can workaround with symbols versioning. But even then we hear
from users that out pthread_mutex_t is still way larger, specially for
fine grained locking so I am not sure if we do want to extend it.
> That said; if we're going to do the whole futex-vector thing, we really
> do need a new interface, because the futex multiplex monster is about to
> crumble (see the fun wrt timeouts for example).
>
> And if we're going to do a new interface, we ought to make one that can
> solve all these problems. Now, ideally glibc will bring forth some
> opinions, but if they don't want to play, we'll go back to the good old
> days of non-standard locking libraries.. we're halfway there already due
> to glibc not wanting to break with POSIX were we know POSIX was just
> dead wrong broken.
>
> See: https://github.com/dvhart/librtpi
You are right, we don't really want to break POSIX requirements in this
regard because users constantly come with scenarios where they do expect
our implementation to be conformant [1]. And even now, there are case we
don't get it fully right [2] and it is really hard to fix such issues.
If I recall correctly from a recent plumber couple of years ago about
the librtpi, the presents stated their implement do not follow POSIX
standard by design. It suits then for their required work, but it is
not what we really aim for glibc. We *might* try to provide as an
extension, but even then I am not if it would be fully possible due
API constraints.
So, regarding the futex2 we might try to support it eventually; but if
this newer interface is not a really a superset of futex1 we won't
put much effort. Supporting newer syscall requires an extra effort from
glibc, we need to keep fallback for older ones in case the kernel is
too old and it also imposes runtime costs.
Also currently we don't have a specific usage. The proposed patch to
add the 'pthread_mutex_lock_any' and 'pthreada_timedlock_any' [3]
also did not gave much detail in realword usages or how it can be
leveraged.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=13165
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=25847
[3] https://sourceware.org/pipermail/libc-alpha/2019-July/105422.html
* Adhemerval Zanella:
> Also currently we don't have a specific usage. The proposed patch to
> add the 'pthread_mutex_lock_any' and 'pthreada_timedlock_any' [3]
> also did not gave much detail in realword usages or how it can be
> leveraged.
The current rwlock implementation in glibc uses a torn 32-bit futex read
which is part of an atomically updated 64-bit word. That's just really,
really ugly, and I suspect we could make that go away with futex2.
Thanks,
Florian