This one is rather tricky, but changing the initialization of
current_val should give this the same effect. Based on ffmpeg's change
here: https://ffmpeg.org/pipermail/ffmpeg-devel/2014-October/164556.html
Quoting from them:
> The second reason is __atomic_compare_exchange_n(), and how it differs from
> __sync_val_compare_and_swap().
> While the latter returns *ptr as it was before the operation, the former
> doesn't and instead copies *ptr to oldval if the result of the
> comparison is false. This means that returning oldval will match the old behavoir
> without having to change the wrapper.
> A disassemble example from libavutil/buffer.o however hints that the
> __atomic function may be slower because of it writting oldval.
pid_t getpid_cached(void) {
static bool installed = false;
- pid_t current_value;
+ pid_t current_value = CACHED_PID_UNSET;
/* getpid_cached() is much like getpid(), but caches the value in local memory, to avoid having to invoke a
* system call each time. This restores glibc behaviour from before 2.24, when getpid() was unconditionally
* https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=c579f48edba88380635ab98cb612030e3ed8691e
*/
- current_value = __sync_val_compare_and_swap(&cached_pid, CACHED_PID_UNSET, CACHED_PID_BUSY);
+ __atomic_compare_exchange_n(
+ &cached_pid,
+ ¤t_value,
+ CACHED_PID_BUSY,
+ false,
+ __ATOMIC_SEQ_CST,
+ __ATOMIC_SEQ_CST);
switch (current_value) {