Thanks Rasmus and Jonathan for your comments and suggestions. > On 20 May 2020, at 12:07, Jonathan Wakely <jwakely....@gmail.com> wrote: > > On Wed, 20 May 2020 at 09:44, Rasmus Villemoes <r...@rasmusvillemoes.dk> > wrote: >> >> Hi >> >> The condition variable implementation added in commit 806dd0472f56fd >> seems to fall into the trap(s) pointed out in the paper >> >> http://birrell.org/andrew/papers/ImplementingCVs.pdf >> >> in particular, the "if no thread is currently waiting, signal should not >> leave a full semaphore so a following _wait will just fall through". >> >> Now, libgcc/gthr.h doesn't really spell out whether __gthread condition >> variables are supposed to behave as POSIX condition variables, so I >> don't know if it's a problem in practice. > > The libstdc++ std::condition_variable assumes POSIX-ish semantics for > __gthread_cond_t. It certainly assumes that a signal/broadcast will > only wake threads that are currently waiting, not affect waits that > haven't started yet. So it seems gthr-vxworks.h should not set > __GTHREADS_CXX0X, or libstdc++ needs a different condition_variable > implementation for VxWorks. > > Libstdc++ also assumes this requirement of pthread_cond_destroy is met: > "It shall be safe to destroy an initialized condition variable upon > which no threads are currently blocked." > This means it's OK for another thread to destroy the CV after the > semTake (*cond, WAIT_FOREVER) statement in __ghtread_cond_wait, even > if the semTake (*mutex, WAIT_FOREVER) statement hasn't happened. The > code looks OK as far as that requirement goes.
> I'm not sure how many other implicit assumptions libstdc++ makes about > POSIX-ish semantics. Ok. The goal was to provide an implementation suitable for libstdc++ so we'll look into this further. Thanks again for the pointers and insights on expectations! > As an aside, it looks like there are enough libgcc/config/*vx* files > to justify creating a libgcc/config/vxworks sub-directory. Indeed. I'll add this to the list :) Olivier
