LIU Hao <lh_mo...@126.com> writes: > 在 2021-10-30 03:34, Óscar Fuentes 写道: >> I was about to start using <atomic> in my projects but then bumped into >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037 >> I can reproduce the problem with gcc 11.2 from MSYS2 and, needless >> to >> say, pictures <atomic> as "completely broken". >> Is the Mingw-w64 community aware of issues like this? Is there any >> ongoing work on this area I can contribute to? >> IIRC time ago there was some initiative for moving away from the >> pthreads emulation layer. >> > > Those atomic operations that map directly to hardware instructions > (such as `std::atomic<int>`) should be quite reliable, because they > are simple enough. > > The winpthreads mutex, despite the inefficiency, should also be quite > reliable. But there are some issues with the winpthread condition > variable (including occasional deadlocks), which have never been > addressed. > > Note you mentioned `std::atomic_flag` in the report above. I haven't > looked at libsstdc++ source but I suppose it uses global mutexes and > condition variables from libatomic. Therefore the `wait` function may > suffer from the condition variable bug.
The reproducer in the gcc bugzilla ticket does not use condition variables. It never enters pthread_cond_signal. So we have a bug elsewhere. OTOH, I can not reproduce the deadlock reported in https://sourceforge.net/p/mingw-w64/bugs/774/ _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
