All the way back in commit 1670ee5aba, the default clock for
condition variables was set to `CLOCK_MONOTONIC`, because there was no
other clock available.
However, if a condition variable is initialized without any additional
attributes by an application, they sometimes assume that the absolute
time that is passed to e.g. `pthread_cond_timedwait` is actually based
on a realtime clock, as can be seen here in SDL2:
6f419bdf5f/src/thread/pthread/SDL_syscond.c (L99)
Additionally, the glibc implementation defaults to a realtime clock:
aac54dcd37/nptl/pthread_cond_init.c (L42)
...so we probably should do so as well :^)
It would be enough to use relaxed ordering here if it weren't for
the mutex, which we also need to store and retrieve. To ensure the
pthread_cond_broadcast() call sees the store, use release and acquire
as appropriate. Thankfully, both of these are on the slow paths.
This implementation features a fast path for pthread_cond_signal() and
pthread_cond_broadcast() for the case there's no thread waiting, and
does not exhibit the "thundering herd" issue in
pthread_cond_broadcast().
Fixes https://github.com/SerenityOS/serenity/issues/8432
