[patch] Rework the condition variables support for VxWorks

[Olivier Hainque]

This change reworks the condition variables support for VxWorks
to address the very legit points raised by Rasmus in

  https://gcc.gnu.org/pipermail/gcc/2020-May/232524.html

While some of the issues were taken care of by the use of semFlush,
a few others were indeed calling for adjustments.

We first considered resorting to the condvarLib library available
in VxWorks7. Unfortunately, it is vx7 only and we wanted something working
for at least vx 6.9 as well. It also turned out requiring the use of
recursive mutexes for condVarWait, which seemed unnecessarily constraining.

Instead, this change corrects the sequencing logic in a few places and
leverages the semExchange API to ensure the key atomicity requirement on
cond_wait operations.

Thanks to Alex for coming up with the correction! 

And thanks again to Rasmus and Jonathan for raising the point
and clarifying the libstdc++ expectations.

As for the other patches in the series I'm sending, this has been
used for a few months in gcc-9 based production compilers targeting
vxworks 7. It also passed a build & test sequence for powerpc-vxworks
7 and 6.9 with gcc-10 and a sanity check build with a recent mainline.

Olivier

2020-10-01  Alexandre Oliva  <oliva@adacore.com>

libgcc/
        * config/gthr-vxworks-thread.c: Include stdlib.h.
        (tls_delete_hook): Prototype it.
        (__gthread_cond_signal): Return early if no waiters.  Consume
        signal in case the semaphore got full.  Use semInfoGet instead
	of kernel-mode-only semInfo.
        (__gthread_cond_timedwait): Use semExchange.  Always take the
        mutex again before returning.
        * config/gthr-vxworks-cond.c (__ghtread_cond_wait): Likewise.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Rework-the-gthr-cond-variables-support-for-VxWorks.patch
Type: application/octet-stream
Size: 4201 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20201001/cb20edf0/attachment.obj>