Saturday, November 11, 2023

Digest for comp.lang.c++@googlegroups.com - 11 updates in 1 topic

Branimir Maksimovic <branimir.maksimovic@icloud.com>: Nov 11 02:59AM

> }
 
> 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/
Bonita Montero <Bonita.Montero@gmail.com>: Nov 11 04:53AM +0100

Am 10.11.2023 um 21:44 schrieb Chris M. Thomasson:
 
>> 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 ?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 10 08:09PM -0800

On 11/10/2023 7:53 PM, Bonita Montero wrote:
>>> 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.
Branimir Maksimovic <branimir.maksimovic@icloud.com>: Nov 11 04:25AM

>>> 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 ?
 
There is no bug. I simply used thread instead of jtrhead
as Apple g++ implementation does not have it.
Since thread destructor throws exception
if thread is still running, it calls terminate
handler.
Real g++ implementation works:
Lola@MacBook-Air News % ./cond_var
3566.26
3292.95
Lola@MacBook-Air News %
Same thing is happening with all other
I showed previously.
I placed switch -std=c++20 in Apple's g++,
but anyway it does not have jthread.
take a look:
Lola@MacBook-Air News % clang++ -O3 cond_var.cpp test_cond.cpp -o cond_var -std=c++20 -D__unix__
test_cond.cpp:48:9: error: unknown type name 'jthread'; did you mean 'thread'?
vector<jthread> threads;
^~~~~~~
thread
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/thread:225:24: note: 'thread' declared here
class _LIBCPP_TYPE_VIS thread
^
1 error generated.
Lola@MacBook-Air News %
 
--
 
7-77-777, Evil Sinner!
https://www.linkedin.com/in/branimir-maksimovic-6762bbaa/
Bonita Montero <Bonita.Montero@gmail.com>: Nov 11 07:07AM +0100

Am 11.11.2023 um 05:25 schrieb Branimir Maksimovic:
 
> Lola@MacBook-Air News % ./cond_var
> 3566.26
> 3292.95
 
Same as on my 3990X Linux PC: 8% faster.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 11 11:41AM +0100

I think I've put the finishing touches to the code now. For the mutex
part I introduced spinning, which I adopted from glibc. Spinning usually
makes little sense for producer-consumer relationships because the time
it takes to put an item in the queue or take it out of it is usually
very short, and the time it takes to produce the item before and consume
it afterwards is usually very short is usually orders of magnitude
higher; Therefore, a collision during locking can occur quite rarely.
Nevertheless, I can also imagine cases where items are produced and
consumed with high frequency, and spinning could make sense there.
 
So, here are the two changed files:
 
// monitor.h
 
#pragma once
#if defined(_WIN32)
#define NOMINMAX
#include <Windows.h>
#elif defined(__unix__)
#include <sys/types.h>
#include <sys/sem.h>
#include <sys/stat.h>
#else
#error unsupported platform
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)