|
|
Boost : |
From: David Bien (davidbien_at_[hidden])
Date: 2024-04-26 19:23:06
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_at_[hidden]> on behalf of David Bien via Boost <boost_at_[hidden]>
Sent: Friday, April 26, 2024 11:30 AM
To: Peter Dimov <pdimov_at_[hidden]>; boost_at_[hidden] <boost_at_[hidden]>
Cc: David Bien <davidbien_at_[hidden]>
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_at_[hidden]>
Sent: Friday, April 26, 2024 11:25 AM
To: 'David Bien' <davidbien_at_[hidden]>; boost_at_[hidden] <boost_at_[hidden]>
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_at_[hidden]>
> Sent: Friday, April 26, 2024 11:15 AM
> To: 'David Bien' <davidbien_at_[hidden]>; boost_at_[hidden]
> <boost_at_[hidden]>
> 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>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk