- A Java- / .NET-like monitor - 4 Updates
- Relacy Rocks... - 1 Update
| Branimir Maksimovic <branimir.maksimovic@icloud.com>: Nov 10 01:56PM > on bare metal it actually is faster. And I was really surprised > that the MS condvar implementation is that extremely slow compared > to my monitor. here is what i got on macOS: (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT * frame #0: 0x000000018c33d0bc libsystem_kernel.dylib`__pthread_kill + 8 frame #1: 0x000000018c374cc0 libsystem_pthread.dylib`pthread_kill + 288 frame #2: 0x000000018c280a40 libsystem_c.dylib`abort + 180 frame #3: 0x000000018c32c070 libc++abi.dylib`abort_message + 132 frame #4: 0x000000018c31c004 libc++abi.dylib`demangling_terminate_handler() + 52 frame #5: 0x000000018c32b434 libc++abi.dylib`std::__terminate(void (*)()) + 16 frame #6: 0x000000018c32b390 libc++abi.dylib`std::terminate() + 36 frame #7: 0x000000018c2aa714 libc++.1.dylib`std::__1::thread::~thread() + 32 frame #8: 0x0000000100007cd0 cond_var`void std::__1::__destroy_at[abi:v160006]<std::__1::thread, 0>(__loc=0x00006000036c4028) at construct_at.h:66:13 frame #9: 0x0000000100007cac cond_var`void std::__1::destroy_at[abi:v160006]<std::__1::thread, 0>(__loc=0x00006000036c4028) at construct_at.h:101:5 frame #10: 0x0000000100007c10 cond_var`void std::__1::allocator_traits<std::__1::allocator<std::__1::thread>>::destroy[abi:v160006]<std::__1::thread, void, void>((null)=0x000000016fdff040, __p=0x00006000036c4028) at allocator_traits.h:323:9 frame #11: 0x000000010000a090 cond_var`std::__1::vector<std::__1::thread, std::__1::allocator<std::__1::thread>>::__base_destruct_at_end[abi:v160006](this=0x000000016fdff030 size=2, __new_last=0x00006000036c4020) at vector:836:9 frame #12: 0x0000000100009d10 cond_var`std::__1::vector<std::__1::thread, std::__1::allocator<std::__1::thread>>::__destruct_at_end[abi:v160006](this=0x000000016fdff030 size=2, __new_last=0x00006000036c4020) at vector:724:9 frame #13: 0x00000001000063d4 cond_var`std::__1::vector<std::__1::thread, std::__1::allocator<std::__1::thread>>::resize(this=0x000000016fdff030 size=2, __sz=0) at vector:1912:15 frame #14: 0x0000000100005eec cond_var`main(argc=1, argv=0x000000016fdff420) at test_cond.cpp:52:10 frame #15: 0x000000018bff50e0 dyld`start + 2360 -- 7-77-777, Evil Sinner! https://www.linkedin.com/in/branimir-maksimovic-6762bbaa/ |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 10 03:08PM +0100 Am 10.11.2023 um 14:56 schrieb Branimir Maksimovic: > frame #13: 0x00000001000063d4 cond_var`std::__1::vector<std::__1::thread, std::__1::allocator<std::__1::thread>>::resize(this=0x000000016fdff030 size=2, __sz=0) at vector:1912:15 > frame #14: 0x0000000100005eec cond_var`main(argc=1, argv=0x000000016fdff420) at test_cond.cpp:52:10 > frame #15: 0x000000018bff50e0 dyld`start + 2360 It seems that resizing the thread-vector while doing an emplace_back(), which itself seems to be inlined, fails. I don't know why. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 10 03:15PM +0100 Am 10.11.2023 um 15:08 schrieb Bonita Montero: >> frame #15: 0x000000018bff50e0 dyld`start + 2360 > It seems that resizing the thread-vector while doing an emplace_back(), > which itself seems to be inlined, fails. I don't know why. I think I've got it: I'm using C++20 jthreads which are joined on the destruction of the jthread object. I'm just resizing the jthread vector to join both threads. But your jthread-implementation seems to behave like a normal C++11 thread which calls abort() on destruction when a thread which is joinable and not joind. You may verify that with this code. #include <thread> using namespace std; int main() { (void)jthread( []() { this_thread::sleep_for( 1s ); } ); } The temporary is very like to be destructed before the thread is terminated. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 10 12:44PM -0800 On 11/10/2023 6:08 AM, Bonita Montero wrote: >> frame #15: 0x000000018bff50e0 dyld`start + 2360 > It seems that resizing the thread-vector while doing an emplace_back(), > which itself seems to be inlined, fails. I don't know why. You should of modeled in a race-detector first! |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 10 12:44PM -0800 On 11/9/2023 12:12 AM, Chris M. Thomasson wrote: > Take notice that Relacy can model windows sync primitives, and C++... > rl::rl_HANDLE, rl_CreateEvent, ect, and such... ;^) > https://github.com/dvyukov/relacy [...] Fwiw, you do not need to have windows installed to play around with Relacy. It simulates windows primitives, and even PThread primitives. |
| 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