Ok, so I asked copilot​ - LMAO!!! It suggested, and I didn't think it made sense but I tried it, to change the class member declaration order to destruct the std::thread first​. std::weak_ptr< CGlobals > m_wpGlobals; std::unordered_map< boost::uuids::uuid, CSession, std::hash< boost::uuids::uuid > > m_sessions; boost::shared_mutex m_mutex; std::chrono::minutes m_nMinutesCleanupSession; bool m_fRunning; boost::mutex m_cvMutex; boost::condition_variable m_cv; std::thread m_thread; I had it somewhere in the middle - but importantly above the m_cv and m_cvMutex. I ran it thirty times or so and didn't get a race or an EBUSY. Granted this is no guarantee - but it always failed before within a few runs. Oh, and I also changed this - but things still failed after this change. ~CShareMgr() { { boost::lock_guard< boost::mutex > lock( m_cvMutex ); m_fRunning = false; m_cv.notify_one(); // moved this up from below the block. } if ( m_thread.joinable() ) { m_thread.join(); } } Does the change to destructing the std::thread() first make any sense to anyone at all? Cuz it doesn't make sense to me - the presumption is that the thread wasn't in a joinable state when joinable() was called? A bit confused, bien ________________________________ From: Boost <boost-bounces@lists.boost.org> on behalf of David Bien via Boost <boost@lists.boost.org> Sent: Friday, April 26, 2024 11:30 AM To: Peter Dimov <pdimov@gmail.com>; boost@lists.boost.org <boost@lists.boost.org> Cc: David Bien <davidbien@hotmail.com> Subject: Re: [boost] BOOST_THREAD_HAS_EINTR_BUG... "Incidentally, underscore followed by a capital letter is reserved to the implementation and you're not supposed to use such identifiers." Yeah, people have been telling me that for 35 years of writing C++ - the fact is that the compiler mangles every single name - as you well know... I literally have never encountered a single problem due to my coding style. Yeah, the pattern looks correct to me as well - I mean if the m_cv and m_cvMutex are passing then the thread should exit, no? It seems foolproof - the code that is - no reason it shouldn't exit the cleanup thread. I'd love for someone to poke holes in this theory. bien ________________________________ From: Peter Dimov <pdimov@gmail.com> Sent: Friday, April 26, 2024 11:25 AM To: 'David Bien' <davidbien@hotmail.com>; boost@lists.boost.org <boost@lists.boost.org> Subject: RE: [boost] BOOST_THREAD_HAS_EINTR_BUG... David Bien wrote:
Sure, but then there must be a bug in my code... do you see one? It's pretty simple - and once again has worked for many weeks of testing under other platforms.
No, I don't see a bug in the code you posted. (Assuming that m_thread is joinable and executes _CleanupThread.) Incidentally, underscore followed by a capital letter is reserved to the implementation and you're not supposed to use such identifiers.
________________________________
From: Peter Dimov <pdimov@gmail.com> Sent: Friday, April 26, 2024 11:15 AM To: 'David Bien' <davidbien@hotmail.com>; boost@lists.boost.org <boost@lists.boost.org> Subject: RE: [boost] BOOST_THREAD_HAS_EINTR_BUG...
David Bien wrote:
When it aborts the return is EBUSY.
EBUSY means that you're destroying a locked mutex, so the abort is legitimate.
_______________________________________________ Unsubscribe & other changes: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.boost.org%2Fmailman%2Flistinfo.cgi%2Fboost&data=05%7C02%7C%7Cebf66098729e4302d7cc08dc661f0555%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638497530615589376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=CI1k7on8sa8nfV%2Be8KRpGAzRXmeNiW%2FVrQL7ZCGB0%2Fc%3D&reserved=0<http://lists.boost.org/mailman/listinfo.cgi/boost>