[Boost-users] Abwesenheitsnachricht: boost::detail::spinlock problem
Derzeit bin ich nicht im Hause Ihre E-Mail wird nicht weitergeleitet. In dringenden Fällen bitte supp...@ditec-gmbh.de oder Telefonhotline +49-6221-31698-110 oder die Zentrale +49-6221-31698-0 kontaktieren. Mit freundlichen Grüßen Dr. Sören Textor --- DiTEC Dr. Siegfried Kahlich & Dierk Langer GmbH Im Breitspiel 19 | 69126 Heidelberg | Germany Handelsregister | Mannheim | HRB 341229 Dieses Dokument ist vertraulich zu behandeln. Die Weitergabe, sowie Vervielfältigung, Verwertung und Mitteilung seines Inhalts ist nur mit unserer ausdrücklichen Genehmigung gestattet. Alle Rechte vorbehalten, insbesondere für den Fall der Schutzrechtsanmeldung. This document has to be treated confidentially. Its contents are not to be passed on, duplicated, exploited or disclosed without our express permission. All rights reserved, especially the right to apply for protective rights. ___ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
[Boost-users] boost::detail::spinlock problem
Hi I'm using boost::detail::spinlock (boost-1.81) in code that compiles on both Visual Studio and gcc. I've hit a problem on the gcc build where the underlying spinlock member (v_) in spinlock_gcc_atomic.hpp isn't an atomic variable and isn't explicitly initialised (BOOST_DETAIL_SPINLOCK_INIT is defined, but there's no initializer and no constructor). v_ is declared as a non-atomic unsigned char and atomic operations use gcc intrinsics in that file. So v_ needs to be explicitly initialized to 0. When the lock method is called, it just spins as a result. This may be work-in-progress or am I misunderstanding? It seems such a glaring omission. The STL version of the spinlock uses std::atomic which does initialize v_ because it's wrapped up in the atomic template. Also there is a scoped_lock nested class within the boost spinlock. Why have an additional lock guard? Surely std::scoped_lock should be sufficient (or is it there just for testing - if so please comment it). I can overcome the problem (without modifying spinlock_gcc_atomic.hpp) by trying to acquire the lock when I create it and releasing it regardless. Is this a bug in that file? Thanks Cliff ___ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
