- The ultimate thread pool - 10 Updates
- msvc wrt locking errors... - 2 Updates
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 06 07:12AM +0100 Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson: > Can you create a little self-contained example that shows these warnings? Make the pragmas commented and look what the IDE shows as warnings. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 05 10:34PM -0800 On 2/5/2024 10:12 PM, Bonita Montero wrote: > Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson: >> Can you create a little self-contained example that shows these warnings? > Make the pragmas commented and look what the IDE shows as warnings. What is in: ______________________ #include <cassert> #include "thread_pool.h" #include "invoke_on_destruct.h" ______________________ ? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 05 10:36PM -0800 On 2/5/2024 10:34 PM, Chris M. Thomasson wrote: > #include "invoke_on_destruct.h" > ______________________ > ? You have some issues here. These warnings are not for kicks and giggles, so to speak. If these warnings are wrong, you need to file a bug report to the MSVC team. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 05 10:38PM -0800 On 2/5/2024 10:12 PM, Bonita Montero wrote: > Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson: >> Can you create a little self-contained example that shows these warnings? > Make the pragmas commented and look what the IDE shows as warnings. Think about getting a warning free compile. Think about what these warnings actually mean. If you find a bug, report it to the MSVC team. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 05 10:46PM -0800 On 2/5/2024 10:34 PM, Chris M. Thomasson wrote: > #include <cassert> > #include "thread_pool.h" > #include "invoke_on_destruct.h" ^^^^^^^^^^^^^^^^^^^^^^ What is that for? |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 06 11:15AM +0100 Am 06.02.2024 um 07:34 schrieb Chris M. Thomasson: > ______________________ > #include <cassert> > #include "thread_pool.h" The header I posted. > #include "invoke_on_destruct.h" Sth. like experimental::scope_exit, this is my code: #pragma once #include <utility> template<typename Fn> requires requires( Fn fn ) { { fn() }; } struct invoke_on_destruct { private: Fn m_fn; bool m_enabled; public: invoke_on_destruct( Fn &&fn ) : m_fn( std::forward<Fn>( fn ) ), m_enabled( true ) { } ~invoke_on_destruct() { if( m_enabled ) m_fn(); } void operator ()() { if( m_enabled ) m_enabled = false, m_fn(); } void disable() { m_enabled = false; } invoke_on_destruct &enable() { m_enabled = true; return *this; } }; |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 06 11:17AM +0100 Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson: > Think about getting a warning free compile. Think about what these > warnings actually mean. If you find a bug, report it to the MSVC team. Where the compiler warns me there are no errors, these are false warnings. |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 06 02:01PM +0100 Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson: >> Make the pragmas commented and look what the IDE shows as warnings. > Think about getting a warning free compile. Think about what these > warnings actually mean. If you find a bug, report it to the MSVC team. Try this ... void fn( unique_lock<mutex> &lock ) { assert(lock); lock.unlock(); } ... and you'll get a warning. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 06 11:55AM -0800 On 2/6/2024 2:17 AM, Bonita Montero wrote: >> warnings actually mean. If you find a bug, report it to the MSVC team. > Where the compiler warns me there are no errors, > these are false warnings. Well, that deserves a bug report? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 06 12:07PM -0800 On 2/6/2024 5:01 AM, Bonita Montero wrote: > lock.unlock(); > } > ... and you'll get a warning. Fwiw, I get no warning with: { std::unique_lock<std::mutex> lock(m_mutex); assert(lock); lock.unlock(); //lock.unlock(); // this throws an exception. } The interesting part is the code for std::unique_lock: ~unique_lock() noexcept { if (_Owns) { _Pmtx->unlock(); } } I was wondering why std::unique_lock did not try to unlock it twice in the dtor. Well, the code for std::~unique_lock that MSVC is using answers my question. Its that _Owns variable. Humm... |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 05 11:10PM -0800 This is not giving me a warning, but an assertion. I am still wondering why Bonita has to suppress all of those warnings wrt this thread ala MSVC: https://groups.google.com/g/comp.lang.c++/c/pFsb3JI11-k Here is some bugged code I just created, wrt MSVC version 17.8.5. No warnings, but an assertion: https://i.ibb.co/QQFyZQq/image.png code: ____________________________________ #include <iostream> #include <functional> #include <thread> #include <mutex> namespace ct { struct mutex_test { std::mutex m_mutex; void works() { m_mutex.lock(); m_mutex.unlock(); } void foobar() { m_mutex.lock(); //m_mutex.unlock(); YIKES! } }; } int main() { std::cout << "ct_threads... ;^)\n" << std::endl; { ct::mutex_test test; test.works(); test.foobar(); // humm... Kabboom! } return 0; } ____________________________________ Btw, I am going to port my new XCHG based code from Relacy race detector into actual C++ code where we all can play with it. Getting to a point where I need to use it for a project. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 06 12:33AM -0800 On 2/5/2024 11:10 PM, Chris M. Thomasson wrote: > This is not giving me a warning, but an assertion. I am still wondering > why Bonita has to suppress all of those warnings wrt this thread ala MSVC: > https://groups.google.com/g/comp.lang.c++/c/pFsb3JI11-k [...] Sometime tomorrow I can work on this. I need to compile the bugged test code with the warning level bumped up. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment