LIU Hao <[email protected]> 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.
Thank you for your answer. Regarding condition variables, was https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/4bad2ca0.10fd7.16a12174529.Coremail.lh_mouse%40126.com/ forgotten or was it proved wrong? IIRC you implemented a native replacement for winpthreads (to use in gcc/libstc++). What happened to it? _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
