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 <ol...@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.
0001-Rework-the-gthr-cond-variables-support-for-VxWorks.patch
Description: Binary data