Am 09.11.2023 um 06:44 schrieb Chris M. Thomasson:

> Wait morphing is not in the realm of the compiler. It's in the kernel.

Read this:
https://stackoverflow.com/questions/45163701/which-os-platforms-implement-wait-morphing-optimization

On 11/8/2023 9:45 PM, Bonita Montero wrote:
> Am 09.11.2023 um 06:44 schrieb Chris M. Thomasson:
>
>> Wait morphing is not in the realm of the compiler. It's in the kernel.
>
> Read this:
> https://stackoverflow.com/questions/45163701/which-os-platforms-implement-wait-morphing-optimization

Wait morphing can be highly beneficial.

On 11/8/2023 9:48 PM, Chris M. Thomasson wrote:
> On 11/8/2023 9:45 PM, Bonita Montero wrote:
>> Am 09.11.2023 um 06:44 schrieb Chris M. Thomasson:
>>
>>> Wait morphing is not in the realm of the compiler. It's in the kernel.
>>
>> Read this:
>> https://stackoverflow.com/questions/45163701/which-os-platforms-implement-wait-morphing-optimization
>
> Wait morphing can be highly beneficial.

I have to go to work on my fractals right now, will get back to you. I
will mostly have time to port your code into a Relacy unit test sometime
later on tonight or tomorrow. This work will be for free for you. Will
you even appreciate it in any way shape or form? Or mock me?

Am 09.11.2023 um 06:39 schrieb Bonita Montero:
> Am 09.11.2023 um 06:35 schrieb Chris M. Thomasson:
>
>> Wait morphing is a way that shows how interconnected a mutex actually
>> is with a condition variable...
>
> As you can derive from what I said I know what wait morphing is.
> I think wait morphing could be prevented unter systems supporting
> SysV seamphores by allocating a semaphore set of two semaphores
> for each mutex and leaving the second unused until you have a
> condition variable.
>

Sorry, this dosn't work beyond one condvar per mutex.

Am 09.11.2023 um 06:48 schrieb Chris M. Thomasson:
> On 11/8/2023 9:45 PM, Bonita Montero wrote:
>> Am 09.11.2023 um 06:44 schrieb Chris M. Thomasson:
>>
>>> Wait morphing is not in the realm of the compiler. It's in the kernel.
>>
>> Read this:
>> https://stackoverflow.com/questions/45163701/which-os-platforms-implement-wait-morphing-optimization
>
> Wait morphing can be highly beneficial.

Wait morphing isn't necessary under Win32 since you can wait
for the mutexe's binary semaphore and for the condvar's counting
semaphore in one step with WaitForMultipleObjects. Unfortunately
there's nothing under Linux like that.

On 11/8/2023 9:50 PM, Chris M. Thomasson wrote:
> On 11/8/2023 9:48 PM, Chris M. Thomasson wrote:
>> On 11/8/2023 9:45 PM, Bonita Montero wrote:
>>> Am 09.11.2023 um 06:44 schrieb Chris M. Thomasson:
>>>
>>>> Wait morphing is not in the realm of the compiler. It's in the kernel.
>>>
>>> Read this:
>>> https://stackoverflow.com/questions/45163701/which-os-platforms-implement-wait-morphing-optimization
>>
>> Wait morphing can be highly beneficial.
>
> I have to go to work on my fractals right now, will get back to you. I
> will mostly have time to port your code into a Relacy unit test sometime
> later on tonight or tomorrow. This work will be for free for you. Will
> you even appreciate it in any way shape or form? Or mock me?

the funny thing is that I need to model one of my new wait-free queue
experiments in Relacy for use in my rendering engine.

Am 09.11.2023 um 06:42 schrieb Chris M. Thomasson:

> On 11/8/2023 9:40 PM, Bonita Montero wrote:

>> My code is understandable if you know MT-primitives
>> and SysV-IPC. There's nothing "damn" with my code.

> Oh well, like I said, you seem to be a fun person to work with...

If you were here we would go through the code together
and you would immediately understand it.

On 11/8/2023 9:58 PM, Chris M. Thomasson wrote:
> On 11/8/2023 9:50 PM, Chris M. Thomasson wrote:
>> On 11/8/2023 9:48 PM, Chris M. Thomasson wrote:
>>> On 11/8/2023 9:45 PM, Bonita Montero wrote:
>>>> Am 09.11.2023 um 06:44 schrieb Chris M. Thomasson:
>>>>
>>>>> Wait morphing is not in the realm of the compiler. It's in the kernel.
>>>>
>>>> Read this:
>>>> https://stackoverflow.com/questions/45163701/which-os-platforms-implement-wait-morphing-optimization
>>>
>>> Wait morphing can be highly beneficial.
>>
>> I have to go to work on my fractals right now, will get back to you. I
>> will mostly have time to port your code into a Relacy unit test
>> sometime later on tonight or tomorrow. This work will be for free for
>> you. Will you even appreciate it in any way shape or form? Or mock me?
>
> the funny thing is that I need to model one of my new wait-free queue
> experiments in Relacy for use in my rendering engine.

An example of my main experiment:

https://youtu.be/n13GHyYEfLA

All of my own GLSL shaders, pure C++ and openGL.

On 11/8/2023 10:32 PM, Bonita Montero wrote:
> Am 09.11.2023 um 06:42 schrieb Chris M. Thomasson:
>
>> On 11/8/2023 9:40 PM, Bonita Montero wrote:
>
>>> My code is understandable if you know MT-primitives
>>> and SysV-IPC. There's nothing "damn" with my code.
>
>> Oh well, like I said, you seem to be a fun person to work with...
>
> If you were here we would go through the code together
> and you would immediately understand it.
>

Since I have to model one of my experimental algorithms in Relacy
anyway, well, I will be right up in it. Wrt my code, well, its trying to
make some fractals go volumetric and I need to highly efficient and
specialized LIFO/FIFO stack/queue system for it. They are running on the
CPU, I might even be able to get it run in shaders, but for now, I need
to work on modeling my sketch of my code in Relacy, create some test
units, and give it a go. Fwiw, here is one of my vector fields:

https://youtu.be/poXeq5V0dso

This used an older queue of mine to help distribute the field processing
across multiple processors.

On 11/8/2023 10:54 PM, Chris M. Thomasson wrote:
> On 11/8/2023 10:32 PM, Bonita Montero wrote:
>> Am 09.11.2023 um 06:42 schrieb Chris M. Thomasson:
>>
>>> On 11/8/2023 9:40 PM, Bonita Montero wrote:
>>
>>>> My code is understandable if you know MT-primitives
>>>> and SysV-IPC. There's nothing "damn" with my code.
>>
>>> Oh well, like I said, you seem to be a fun person to work with...
>>
>> If you were here we would go through the code together
>> and you would immediately understand it.
>>
>
> Since I have to model one of my experimental algorithms in Relacy
> anyway, well, I will be right up in it. Wrt my code, well, its trying to
> make some fractals go volumetric and I need to highly efficient and
> specialized LIFO/FIFO stack/queue system for it. They are running on the
> CPU, I might even be able to get it run in shaders, but for now, I need
> to work on modeling my sketch of my code in Relacy, create some test
> units, and give it a go. Fwiw, here is one of my vector fields:
>
> https://youtu.be/poXeq5V0dso
>
> This used an older queue of mine to help distribute the field processing
> across multiple processors.

Fwiw, this one is basically embarrassingly parallel to create each
frame. Well, that is kind of cheating wrt embarrassingly parallel, but,
oh well:

https://youtu.be/DrPp6xfLe4Q

This one is from a recursive algorithm of mine, not too efficient wrt
the generation part that gives me my field points to work with. It takes
a while to render an animation in 4k. The recursive nature of it can
blow a threads stack if I get too detailed. So, I need to refine my
current quick and dirty proof of concept code, so to speak. It is kind
of embarrassingly parallel...

Am 09.11.2023 um 06:48 schrieb Chris M. Thomasson:

> Wait morphing can be highly beneficial.

I just checkes how many voluntary context switches I have under Linux
when having a poing-pong between two theads serving a common mutex and
individual condvars.

#include <iostream>
#include <thread>
#include <mutex>
#include <condition_variable>
#include <atomic>
#include <sys/resource.h>

using namespace std;

int main()
{ mutex mtx;
struct wait_t
{
bool signal;
condition_variable cond;
} waitA, waitB;
constexpr size_t ROUNDS = 100'000;
atomic<uint64_t> switches( 0 );
auto thr = [&]( wait_t &waitMe, wait_t &waitYou )
{
for( size_t r = ROUNDS; r--; )
{
unique_lock<mutex> lock( mtx );
while( !waitMe.signal )
waitMe.cond.wait( lock );
waitMe.signal = false;
waitYou.signal = true;
waitYou.cond.notify_one();
}
rusage ru;
if( getrusage( RUSAGE_THREAD, &ru ) )
terminate();
switches += ru.ru_nvcsw;
};
waitA.signal = true;
waitA.cond.notify_one();
jthread
thrA( thr, ref( waitA ), ref( waitB ) ),
thrB( thr, ref( waitB ), ref( waitA ) );
thrA.join();
thrB.join();
cout << switches << endl;
}

The code prints about ROUNDS * context switches, that's great.

Am 09.11.2023 um 08:01 schrieb Bonita Montero:
> Am 09.11.2023 um 06:48 schrieb Chris M. Thomasson:
>
>> Wait morphing can be highly beneficial.
>
>
> I just checkes how many voluntary context switches I have under Linux
> when having a poing-pong between two theads serving a common mutex and
> individual condvars.
>
> #include <iostream>
> #include <thread>
> #include <mutex>
> #include <condition_variable>
> #include <atomic>
> #include <sys/resource.h>
>
> using namespace std;
>
> int main()
> {
>     mutex mtx;
>     struct wait_t
>     {
>         bool signal;
>         condition_variable cond;
>     } waitA, waitB;
>     constexpr size_t ROUNDS = 100'000;
>     atomic<uint64_t> switches( 0 );
>     auto thr = [&]( wait_t &waitMe, wait_t &waitYou )
>     {
>         for( size_t r = ROUNDS; r--; )
>         {
>             unique_lock<mutex> lock( mtx );
>             while( !waitMe.signal )
>                 waitMe.cond.wait( lock );
>             waitMe.signal = false;
>             waitYou.signal = true;
>             waitYou.cond.notify_one();
>         }
>         rusage ru;
>         if( getrusage( RUSAGE_THREAD, &ru ) )
>             terminate();
>         switches += ru.ru_nvcsw;
>     };
>     waitA.signal = true;
>     waitA.cond.notify_one();
>     jthread
>         thrA( thr, ref( waitA ), ref( waitB ) ),
>         thrB( thr, ref( waitB ), ref( waitA ) );
>     thrA.join();
>     thrB.join();
>     cout << switches << endl;
> }
>
> The code prints about ROUNDS * context switches, that's great.
* 2

On 11/8/2023 11:01 PM, Chris M. Thomasson wrote:
> On 11/8/2023 10:54 PM, Chris M. Thomasson wrote:
>> On 11/8/2023 10:32 PM, Bonita Montero wrote:
>>> Am 09.11.2023 um 06:42 schrieb Chris M. Thomasson:
>>>
>>>> On 11/8/2023 9:40 PM, Bonita Montero wrote:
>>>
>>>>> My code is understandable if you know MT-primitives
>>>>> and SysV-IPC. There's nothing "damn" with my code.
>>>
>>>> Oh well, like I said, you seem to be a fun person to work with...
>>>
>>> If you were here we would go through the code together
>>> and you would immediately understand it.
>>>
>>
>> Since I have to model one of my experimental algorithms in Relacy
>> anyway, well, I will be right up in it. Wrt my code, well, its trying
>> to make some fractals go volumetric and I need to highly efficient and
>> specialized LIFO/FIFO stack/queue system for it. They are running on
>> the CPU, I might even be able to get it run in shaders, but for now, I
>> need to work on modeling my sketch of my code in Relacy, create some
>> test units, and give it a go. Fwiw, here is one of my vector fields:
>>
>> https://youtu.be/poXeq5V0dso
>>
>> This used an older queue of mine to help distribute the field
>> processing across multiple processors.
>
> Fwiw, this one is basically embarrassingly parallel to create each
> frame. Well, that is kind of cheating wrt embarrassingly parallel, but,
> oh well:
>
> https://youtu.be/DrPp6xfLe4Q
>
> This one is from a recursive algorithm of mine, not too efficient wrt
> the generation part that gives me my field points to work with. It takes
> a while to render an animation in 4k. The recursive nature of it can
> blow a threads stack if I get too detailed. So, I need to refine my
> current quick and dirty proof of concept code, so to speak. It is kind
> of embarrassingly parallel...

oh shit, I forgot the damn link:

https://youtu.be/YsAkm0VlCsw
(should be 4k, damn it!)

Also, this one is ripe for for improvement. I just know that my new
queue system is going to work for it wrt generating its frames.

https://youtu.be/HwIkk9zENcg

Will create another thread to continue this.

I did a test of my monitor against two mutexes and two condition
variables, playing pingpong with each other. On Windows my imple-
mentation is about 12 times faster than the mentioned mutex with
condvar on a AMD 7950X Zen4 16 core system. Under WSL2 on the
same machine the Linux implementation is 12% faster than my code.
On Linux bare metal with a Zen2 3990X 64 core system my code is
about 8.5% faster.
As I recently found in this that a wait() incurs only one context
switch back and forth I thought my code woudln't be faster, but
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.

#include <iostream>
#include <thread>
#include <chrono>
#include <vector>
#include <mutex>
#include <condition_variable>
#include "monitor.h"

using namespace std;
using namespace chrono;

int main( int argc, char **argv )
{ atomic_int32_t tSum;
auto time = [&]( auto fn )
{
tSum = 0;
auto start = high_resolution_clock::now();
fn();
tSum += (int64_t)duration_cast<nanoseconds>(
high_resolution_clock::now() - start ).count();
};
constexpr size_t ROUNDS = 100'000;
struct not_t
{
monitor mon;
bool notifiy;
} notA { {}, true }, notB { {}, false };
notA.notifiy = true;
auto monThr = [&]( not_t &me, not_t &you )
{
time( [&]()
{
for( size_t r = ROUNDS; r; --r )
{
me.mon.lock();
for( ; !me.notifiy; me.mon.wait() );
me.notifiy = false;
me.mon.unlock();
you.mon.lock();
you.notifiy = true;
you.mon.notify();
you.mon.unlock();
}
} );
};
vector<jthread> threads;
threads.reserve( 0 );
threads.emplace_back( monThr, ref( notA ), ref( notB ) ),
threads.emplace_back( monThr, ref( notB ), ref( notA ) );
threads.resize( 0 );
cout << tSum / ((double)ROUNDS * 2) << endl;
struct cv_t
{
mutex mtx;
condition_variable cv;
bool signal;
} cvA = { {}, {}, true }, cvB = { {}, {}, false };
auto cvThr = [&]( cv_t &cvMe, cv_t &cvYou )
{
time( [&]()
{
for( size_t r = ROUNDS; r; --r )
{
unique_lock<mutex> lockMe( cvMe.mtx );
for( ; !cvMe.signal; cvMe.cv.wait( lockMe ) );
cvMe.signal = false;
lockMe.unlock();
unique_lock<mutex> lockYou( cvYou.mtx );
cvYou.signal = true;
cvYou.cv.notify_one();
}
} );
};
threads.emplace_back( cvThr, ref( cvA ), ref( cvB ) );
threads.emplace_back( cvThr, ref( cvB ), ref( cvA ) );
threads.resize( 0 );
cout << tSum / ((double)ROUNDS * 2) << endl;
}

On 11/9/2023 1:07 AM, Bonita Montero wrote:
> I did a test of my monitor against two mutexes and two condition
> variables, playing pingpong with each other. On Windows my imple-
> mentation is about 12 times faster than the mentioned mutex with
> condvar on a AMD 7950X Zen4 16 core system. Under WSL2 on the
> same machine the Linux implementation is 12% faster than my code.
> On Linux bare metal with a Zen2 3990X 64 core system my code is
> about 8.5% faster.
> As I recently found in this that a wait() incurs only one context
> switch back and forth I thought my code woudln't be faster, but
> 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.
[...]

I am just starting to model some of my queue code. Its going to fun to
model your monitor and see if its bites the dust.

Am 09.11.2023 um 10:11 schrieb Chris M. Thomasson:

> I am just starting to model some of my queue code. Its going to fun to
> model your monitor and see if its bites the dust.

The advantage under Linux bare metal is only 12%, if you do additional
things in userspace the effect should become smaller. So measuring a
simple bool ping pong shows almost the sole performance of my code.
But you would get a noticeable difference with Windows.

On 11/9/2023 1:17 AM, Bonita Montero wrote:
> Am 09.11.2023 um 10:11 schrieb Chris M. Thomasson:
>
>> I am just starting to model some of my queue code. Its going to fun to
>> model your monitor and see if its bites the dust.
>
> The advantage under Linux bare metal is only 12%, if you do additional
> things in userspace the effect should become smaller. So measuring a
> simple bool ping pong shows almost the sole performance of my code.
> But you would get a noticeable difference with Windows.
>
>
>

Modeling it is not about sheer performance, it is about correctness.

On 11/9/2023 1:22 AM, Chris M. Thomasson wrote:
> On 11/9/2023 1:17 AM, Bonita Montero wrote:
>> Am 09.11.2023 um 10:11 schrieb Chris M. Thomasson:
>>
>>> I am just starting to model some of my queue code. Its going to fun
>>> to model your monitor and see if its bites the dust.
>>
>> The advantage under Linux bare metal is only 12%, if you do additional
>> things in userspace the effect should become smaller. So measuring a
>> simple bool ping pong shows almost the sole performance of my code.
>> But you would get a noticeable difference with Windows.
>>
>>
>>
>
> Modeling it is not about sheer performance, it is about correctness.

Make sure it is sound and correct first, then we can sit back and think
about how to make it much faster...

On 2023-11-09, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> I did a test of my monitor against two mutexes and two condition
> variables, playing pingpong with each other. On Windows my imple-
> mentation is about 12 times faster than the mentioned mutex with
> condvar on a AMD 7950X Zen4 16 core system. Under WSL2 on the
> same machine the Linux implementation is 12% faster than my code.
> On Linux bare metal with a Zen2 3990X 64 core system my code is
> about 8.5% faster.
> As I recently found in this that a wait() incurs only one context
> switch back and forth I thought my code woudln't be faster, but
> 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/

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.

Am 10.11.2023 um 15:08 schrieb Bonita Montero:
> 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.

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.

On 11/10/2023 6:08 AM, Bonita Montero wrote:
> 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.
>

You should of modeled in a race-detector first!

On 2023-11-10, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 10.11.2023 um 15:08 schrieb Bonita Montero:
>> 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.
>
> 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.
>

yes, i don't have jthread. Will try with g++ rather clang...
Yeeee, real g++ has jthread:

--
la@MacBook-Air News % g++-13 -O3 cond_var.cpp test_cond.cpp -o cond_var -std=c++20 -D__unix__
ld: warning: ignoring duplicate libraries: '-lgcc'
Lola@MacBook-Air News % ./cond_var
3881.83
2984.36
Lola@MacBook-Air News %

7-77-777, Evil Sinner!
https://www.linkedin.com/in/branimir-maksimovic-6762bbaa/

Am 10.11.2023 um 21:44 schrieb Chris M. Thomasson:
> On 11/10/2023 6:08 AM, Bonita Montero wrote:
>> 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.
>>
>
> You should of modeled in a race-detector first!

To find bugs inside his jthread-implementation ?

On 11/10/2023 7:53 PM, Bonita Montero wrote:
> Am 10.11.2023 um 21:44 schrieb Chris M. Thomasson:
>> On 11/10/2023 6:08 AM, Bonita Montero wrote:
>>> 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.
>>>
>>
>> You should of modeled in a race-detector first!
>
> To find bugs inside his jthread-implementation ?
>

To help find a bug, yup. Think it up, draft it out, create test units,
model them with a race detector, Get it working... Then, we can think
about improving performance.