Am 19.06.2026 um 22:34 schrieb Chris M. Thomasson:

Not exactly sure what you mean here. Windows and POSIX have basically
the same overhead with preemptive threads. ...

This measures the overhead of a preempted context switch:

#if defined(_WIN32)
#include <Windows.h>
#elif defined(__unix__)
#include <pthread.h>
#endif
#include <iostream>
#include <latch>
#include <thread>
#if defined(_MSC_VER)
#include <intrin.h>
#elif defined(__GNUC__) || defined(__clang__)
#include <x86intrin.h>
#endif

using namespace std;

int main()
{
constexpr size_t ROUNDS = 1'000'000'000;
struct id_tsc { uint64_t id, tsc; };
static id_tsc idTsc( -1, __rdtsc() );
latch latSync( 2 );
atomic_uint64_t aSumTsc = 0;
atomic<size_t> aNChanges = 0;
auto ctxWait = [&]( uint64_t id )
{
#if defined(_WIN32)
SetThreadAffinityMask( GetCurrentThread(), 1 );
#elif defined(__unix__)
cpu_set_t cpuSet;
CPU_ZERO_S(sizeof cpuSet, &cpuSet);
CPU_SET_S(0, sizeof cpuSet, &cpuSet);
pthread_setaffinity_np( pthread_self(), sizeof cpuSet, &cpuSet );
#endif
latSync.arrive_and_wait();
atomic_ref aIdTsc( idTsc );
id_tsc ref = aIdTsc.load( memory_order_relaxed ), niu;
uint64_t sumTsc = 0;
size_t nChanges = 0;
for( size_t r = ROUNDS; r; --r )
{
niu.id = id;
niu.tsc = __rdtsc();
if( aIdTsc.compare_exchange_strong( ref, niu, memory_order_relaxed,
memory_order_relaxed ) ) [[likely]]
{
ref = niu;
continue;
}
if( ref.id == id || ref.id == -1 )
continue;
int64_t dist = niu.tsc - ref.tsc;
if( dist < 0 )
continue;
sumTsc += dist;
++nChanges;
};
aSumTsc += sumTsc;
aNChanges += nChanges;
};
jthread spawned( ctxWait, 0 );
ctxWait( 1 );
cout << (double)aSumTsc / (double)aNChanges << endl;
}

--- PyGate Linux v1.5.17
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 20 Jun 2026 11:47:44 +0200, Bonita Montero wrote:

This measures the overhead of a preempted context switch:

[code omitted]

ldo@theon:c++_try> g++ --std=c++26 context_switch_overhead.cpp
/usr/bin/x86_64-linux-gnu-ld.bfd: /tmp/ccGEPNJM.o: in function `std::__atomic_ref<main::id_tsc, false, false>::load(std::memory_order) const':
context_switch_overhead.cpp:(.text+0x547): undefined reference to `__atomic_load_16'
/usr/bin/x86_64-linux-gnu-ld.bfd: /tmp/ccGEPNJM.o: in function `std::__atomic_ref<main::id_tsc, false, false>::compare_exchange_strong(main::id_tsc&, main::id_tsc, std::memory_order, std::memory_order) const':
context_switch_overhead.cpp:(.text+0x671): undefined reference to `__atomic_compare_exchange_16'
collect2: error: ld returned 1 exit status

Got more errors when I didn?t specify a newer C++ --std option, but
don?t know how to get rid of these ...

--- PyGate Linux v1.5.17
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 20 Jun 2026 22:41:39 -0000 (UTC), I wrote:

On Sat, 20 Jun 2026 11:47:44 +0200, Bonita Montero wrote:

This measures the overhead of a preempted context switch:

[code omitted]

ldo@theon:c++_try> g++ --std=c++26 context_switch_overhead.cpp
/usr/bin/x86_64-linux-gnu-ld.bfd: /tmp/ccGEPNJM.o: in function `std::__atomic_ref<main::id_tsc, false, false>::load(std::memory_order) const':
context_switch_overhead.cpp:(.text+0x547): undefined reference to `__atomic_load_16'
/usr/bin/x86_64-linux-gnu-ld.bfd: /tmp/ccGEPNJM.o: in function `std::__atomic_ref<main::id_tsc, false, false>::compare_exchange_strong(main::id_tsc&, main::id_tsc, std::memory_order, std::memory_order) const':
context_switch_overhead.cpp:(.text+0x671): undefined reference to `__atomic_compare_exchange_16'
collect2: error: ld returned 1 exit status

Got more errors when I didn?t specify a newer C++ --std option, but
don?t know how to get rid of these ...

Got it!

ldo@theon:c++_try> g++ --std=c++23 context_switch_overhead.cpp -latomic
ldo@theon:c++_try> ./a.out
17858.5
ldo@theon:c++_try> g++ --std=c++26 context_switch_overhead.cpp -latomic
ldo@theon:c++_try> ./a.out
18899.2

So what do the numbers mean?

--- PyGate Linux v1.5.17
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Am 21.06.2026 um 01:29 schrieb Lawrence D?Oliveiro:> On Sat, 20 Jun 2026 22:41:39 -0000 (UTC), I wrote:

On Sat, 20 Jun 2026 11:47:44 +0200, Bonita Montero wrote:

This measures the overhead of a preempted context switch:

[code omitted]

ldo@theon:c++_try> g++ --std=c++26 context_switch_overhead.cpp
/usr/bin/x86_64-linux-gnu-ld.bfd: /tmp/ccGEPNJM.o: in function `std::__atomic_ref<main::id_tsc, false, false>::load(std::memory_order) const':
context_switch_overhead.cpp:(.text+0x547): undefined reference

to `__atomic_load_16'

/usr/bin/x86_64-linux-gnu-ld.bfd: /tmp/ccGEPNJM.o: in function `std::__atomic_ref<main::id_tsc, false, false>::compare_exchange_strong(main::id_tsc&, main::id_tsc, std::memory_order, std::memory_order) const':
context_switch_overhead.cpp:(.text+0x671): undefined reference

to `__atomic_compare_exchange_16'

collect2: error: ld returned 1 exit status

Got more errors when I didn?t specify a newer C++ --std option, but
don?t know how to get rid of these ...

Got it!

ldo@theon:c++_try> g++ --std=c++23 context_switch_overhead.cpp

-latomic

ldo@theon:c++_try> ./a.out
17858.5
ldo@theon:c++_try> g++ --std=c++26 context_switch_overhead.cpp

-latomic

ldo@theon:c++_try> ./a.out
18899.2

So what do the numbers mean?

I've improved the code. Now it measures the time for a preempted context
switch in microseconds:

#if defined(_WIN32)
#include <Windows.h>
#elif defined(__unix__)
#include <pthread.h>
#endif
#include <iostream>
#include <latch>
#include <thread>
#include <chrono>

using namespace std;
using namespace chrono;

static bool unbeatable() noexcept;

int main()
{
constexpr size_t ROUNDS = 100'000'000;
static struct id_tsc
{
uint64_t id, tsc;
} idTsc;
latch latSync( 2 );
atomic_uint64_t aSumTsc = 0;
atomic<size_t> aNChanges = 0;
auto ctxWait = [&]( uint64_t id )
{
unbeatable();
latSync.arrive_and_wait();
atomic_ref aIdTsc( idTsc );
id_tsc ref = aIdTsc.load( memory_order_relaxed ), niu;
uint64_t sumTsc = 0;
size_t nChanges = 0;
for( size_t r = ROUNDS; r; --r )
{
niu.id = id;
niu.tsc = (int64_t)high_resolution_clock::now().time_since_epoch().count();
if( aIdTsc.compare_exchange_strong( ref, niu, memory_order_relaxed, memory_order_relaxed ) ) [[likely]]
{
ref = niu;
continue;
}
if( ref.id == id || ref.id == -1 )
continue;
int64_t dist = niu.tsc - ref.tsc;
if( dist < 0 )
continue;
sumTsc += dist;
++nChanges;
};
aSumTsc += sumTsc;
aNChanges += nChanges;
};
jthread spawned( ctxWait, 0 );
ctxWait( 1 );
double
avgNs = (double)aSumTsc / (double)aNChanges,
avgUs = floor( avgNs / (1.0e3 / 10.0) + 0.5 ) / 10.0;
cout << aNChanges << " context switches" << endl;
cout << avgUs << "us per preemted context switch" << endl;
}

static bool unbeatable() noexcept
{
#if defined(_WIN32)
HANDLE hThread = GetCurrentThread();
return SetThreadAffinityMask( hThread, 1 )
&& (SetThreadPriority( hThread, THREAD_PRIORITY_HIGHEST )
|| SetThreadPriority( hThread, THREAD_PRIORITY_TIME_CRITICAL ));
#elif defined(__unix__)
cpu_set_t cpuSet;
CPU_ZERO_S(sizeof cpuSet, &cpuSet);
CPU_SET_S(0, sizeof cpuSet, &cpuSet);
if( pthread_setaffinity_np( pthread_self(), sizeof cpuSet, &cpuSet ) )
return false;
int policy;
struct sched_param param;
return pthread_getschedparam( pthread_self(), &policy, &param ) == 0
&& pthread_setschedprio( pthread_self(),
sched_get_priority_max( policy ) ) == 0;
#endif
}

And this code measures the time for a voluntary context switch (yield)
in microseconds:

#if defined(_WIN32)
#include <Windows.h>
#elif defined(__unix__)
#include <pthread.h>
#endif
#include <iostream>
#include <latch>
#include <thread>
#include <chrono>
#include <cmath>

using namespace std;
using namespace chrono;

static bool unbeatable() noexcept;

int main()
{
constexpr size_t ROUNDS = 1'000'000;
latch latSync( 2 );
atomic_uint64_t aSumTsc = 0;
auto yieldLoop = [&]
{
if( !unbeatable() )
return;
latSync.arrive_and_wait();
size_t nChanges = 0;
auto start = high_resolution_clock::now();
for( size_t r = ROUNDS; r; --r )
this_thread::yield();
aSumTsc += duration_cast<nanoseconds>(high_resolution_clock::now() - start).count();
};
jthread spawned( yieldLoop );
yieldLoop();
spawned.join();
double
avgNs = (double)aSumTsc / (2.0 * (double)ROUNDS),
avgUs = floor( avgNs / (1.0e3 / 10.0) + 0.5 ) / 10.0;
cout << avgUs << "us per voluntary context switch" << endl;
}

static bool unbeatable() noexcept
{
#if defined(_WIN32)
HANDLE hThread = GetCurrentThread();
return SetThreadAffinityMask( hThread, 1 )
&& SetThreadPriority( hThread, THREAD_PRIORITY_HIGHEST )
&& SetThreadPriority( hThread, THREAD_PRIORITY_TIME_CRITICAL );
#elif defined(__unix__)
cpu_set_t cpuSet;
CPU_ZERO_S(sizeof cpuSet, &cpuSet);
CPU_SET_S(0, sizeof cpuSet, &cpuSet);
if( pthread_setaffinity_np( pthread_self(), sizeof cpuSet, &cpuSet ) )
return false;
int policy;
struct sched_param param;
return pthread_getschedparam( pthread_self(), &policy, &param ) == 0
&& pthread_setschedprio( pthread_self(),
sched_get_priority_max( policy ) ) == 0;
#endif
}

--- PyGate Linux v1.5.17
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sun, 21 Jun 2026 09:06:58 +0200, Bonita Montero wrote:

I've improved the code. Now it measures the time for a preempted
context switch in microseconds:

Had to patch this, otherwise it couldn?t find a floor(double) function:

ldo@theon:Bonita Montero progs> diff -u context_switch_overhead_2.cpp{-orig,} --- context_switch_overhead_2.cpp-orig 2026-06-21 19:43:13.682113804 +1200
+++ context_switch_overhead_2.cpp 2026-06-21 19:46:24.228048403 +1200
@@ -12,6 +12,7 @@
#include <latch>
#include <thread>
#include <chrono>
+#include <math.h>

using namespace std;
using namespace chrono;
@@ -64,7 +65,7 @@
avgNs = (double)aSumTsc / (double)aNChanges,
avgUs = floor( avgNs / (1.0e3 / 10.0) + 0.5 ) / 10.0;
cout << aNChanges << " context switches" << endl;
- cout << avgUs << "us per preemted context switch" << endl;
+ cout << avgUs << "us per preempted context switch" << endl;
}

static bool unbeatable() noexcept

Output was:

470 context switches
3.6us per preempted context switch

And this code measures the time for a voluntary context switch
(yield) in microseconds:

Output was:

1.6us per voluntary context switch

--- PyGate Linux v1.5.17
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 21/06/2026 01:29, Lawrence D?Oliveiro wrote:

On Sat, 20 Jun 2026 22:41:39 -0000 (UTC), I wrote:

On Sat, 20 Jun 2026 11:47:44 +0200, Bonita Montero wrote:

This measures the overhead of a preempted context switch:

[code omitted]

ldo@theon:c++_try> g++ --std=c++26 context_switch_overhead.cpp
/usr/bin/x86_64-linux-gnu-ld.bfd: /tmp/ccGEPNJM.o: in function `std::__atomic_ref<main::id_tsc, false, false>::load(std::memory_order) const':
context_switch_overhead.cpp:(.text+0x547): undefined reference to `__atomic_load_16'
/usr/bin/x86_64-linux-gnu-ld.bfd: /tmp/ccGEPNJM.o: in function `std::__atomic_ref<main::id_tsc, false, false>::compare_exchange_strong(main::id_tsc&, main::id_tsc, std::memory_order, std::memory_order) const':
context_switch_overhead.cpp:(.text+0x671): undefined reference to `__atomic_compare_exchange_16'
collect2: error: ld returned 1 exit status

Got more errors when I didn?t specify a newer C++ --std option, but
don?t know how to get rid of these ...

Got it!

ldo@theon:c++_try> g++ --std=c++23 context_switch_overhead.cpp -latomic
ldo@theon:c++_try> ./a.out
17858.5
ldo@theon:c++_try> g++ --std=c++26 context_switch_overhead.cpp -latomic
ldo@theon:c++_try> ./a.out
18899.2

So what do the numbers mean?

When you are compiling without optimisation enabled? Probably nothing,
unless the time taken is only due to code in libraries that you did not compile.


--- PyGate Linux v1.5.17
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Am 21.06.2026 um 12:22 schrieb David Brown:

When you are compiling without optimisation enabled?ÿ Probably nothing, unless the time taken is only due to code in libraries that you did not compile.

The intervals for the thread switches are that long that this
shouldn't make a large difference. The timings just might become
somewhat inaccurate.


--- PyGate Linux v1.5.17
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Bart <bc@freeuk.com> writes:

Regarding compound literals, why is one necessary when assigning to
q' here:

typedef struct {double x, y;} Point;

Point p = {10, 20};
Point q;
q = (Point){30, 40};

The initialisation of 'p' doesn't need it, so can't you just do this:

q = {30, 40};

This idea might be workable in some situations. Certainly though
there are lots of other situations where it is not workable. The
matter can be seen as a language design question: is it better to
have a simpler language that is somewhat less convenient, or is it
better to have a more complicated language that is somewhat more
convenient? Surely most people would _not_ say that C expression
syntax is too simple, and so should be more elaborate. What is the
convenience of the proposed addition worth? Does the cost in added
language complexity justify the benefit in programming convenience?
Would other readers like to weigh in on these question?

--- PyGate Linux v1.5.17
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-06-13 15:38, Bart wrote:

On 13/06/2026 13:35, Janis Papanagnou wrote:

On 2026-06-13 12:14, tTh wrote:

On 6/13/26 12:03, Bart wrote:

Seriously? You have a language where you can literally do this:

ÿÿ #include <stdint.h>
ÿÿ int32_t int32_t;
ÿÿ int32_t = 0;

and that is just fine; just "don't do it"! In that case, we might as
well allow:

ÿÿ int int;

Can you understand how crazy the above looks from outside?

Yes. (And I suppose everyone here understands that!)

Thank you for at least acknowledging that.

Huh? - There's nothing to acknowledge here since it's obvious.

All I intended to say with that was that you are constructing
strange reasoning based on trivialities. - This is actually a
well known and often applied rhetoric move; hunt for agreement
by stating a triviality to get assurance for all the debatable
stuff.

Languages have various possibilities to define their lexical rules,
their syntax, and their semantics.

It's certainly quite common to have _reserved words_ that may only
be used in certain syntactical contexts. But there's also languages
that allow context-depending placement of names that happen to be
also tokens of the language.

Consider, for example, in shell:ÿÿ for for in in do ; do : ; done

In the case of 'int32_t' this is supposedly a core C type but it is
quite unknown to the language until you include a particular header.

Yes. That's something that I (also?) don't think is good language
design. (Many things in "C" I actually consider to be kludges and
quirks; but so what?)

For what reason do you want to discuss all the design decisions of
the C-language? (I'm certainly not the appropriate partner for you
since, depending on the project, I either use "C" - as it is! - or
use another (for the respective task) more appropriate language.)

But, specifically, and for whatever product I develop, I wouldn't
use any proprietary, non-standard, home-brewed product. - So your
(repeated!) advertisement of your toys is meaningless.

[...]

Such pieces of code are a result of a programmer's sick brain and
not the problem of a language.

Such pieces of code are 100% *enabled* by the language so, yes, you can blame the language.

(My statement was on the shell-code. Your examples about "C". Just
noting.)

Since you might not have noticed; I don't write such shell-code.
And I also don't complain (in this respect) about shell's design.

It was about that there's different design options on that level.
What I said was that in either language you have to make decisions.

The shell-designers obviously didn't want to restrict use of values
and names, therefore they consider context.[*] In other languages
they may have different name spaces (cf. Algol 68 "stropping"), or
they use _reserved words_ (as already mentioned). The problem with
the former is that some people (like you) might not like "stropping".
Other folks might not like being restricted in their choice of names
to non-reserved words only. Languages like "C" have reduced these
reserved keywords; at the cost of other syntactic arguable choices,
choices that I personally don't like.

There's obviously no clear "design principle X is good" and "design
principle Y is bad" that fits everyone. (And I'm sure only your own
personal language designs are the only ones that fits your liking.
I'm fine with that.)

I, for example, would like to use common abbreviation for locally
scoped entities, like 'Interface if;' or 'int if = 0;' - but
I cannot do that; I have to follow to the rules that the language
designers have set. (And the 'if' example is not restricted to the
C-language, it's quite common to be a reserved word in languages!)

You cannot fundamentally change "C" as it is; not after more than
five decades (since its birth), and also not after it had been
standardized; it just makes no sense to even start an argument on
that. - If you think it's "bad" don't use it.

These examples are not possible in mine for example,
due to different scoping rules.

That's fine. If you find someone who is interested in your language
he might appreciate it (or not; can't tell, and I don't care).

[...]

Quite draconian, I know! A programmer can still do 'crazy' stuff, but
they have to work harder.

The point that had been tried to convey was that it's *not* in the
first place a language issue; it's an issue the programmer invented.

Consider, example for, text this. From composed punctuation it
language rules is the of words English and. Just not artifacts
possible defined say would such English it to positive language
badly the is create I that is because am you. Would the, text
and rightly, of writer blame you so that.

Oh, wait! I'll translate that for you:

Consider, for example, this text. It is composed of words and
punctuation rules from the English language. I am positive you
would not say that the English language is badly defined just
because it is possible to create such artifacts. You would,
and rightly so, blame the writer of that text.

I'm with you (of course) that a language should be safe, and clearly
defined. But your examples and personal problems [with "C"] are not
rooted in the language (that it allows writing stupid things) but in
the person who writes such code, either in practice or (as you) just
for purpose of an argument.

The attitude here seems to be, if you can write nonsense in any language anyway, then why bother making it harder to do so? Let's have fewer
rules and make it easier!

Can't tell (and don't want to speak) about attitudes. What repeatedly
had been said here was that you cannot change the "C" language just
as you (or anyone else) would like. - "C" is not important enough for
me to engage here. But if you feel there's something essential that
should (and could, without breaking anything) be changed, I'd suggest
to contact the standards group and submit a proposal.

Janis

[*] But note that they also used 'do'...'done' instead of 'do'...'od'
because of existence of the Unix 'od' command.

[...]

--- PyGate Linux v1.5.17
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 6/12/2026 4:15 AM, Bonita Montero wrote:

Am 12.06.2026 um 06:19 schrieb Chris M. Thomasson:

The fibers float along the threads... ;^)

If you have as many fibres as you otherwise would have coroutines
and the number is lage you waste a lot of memory.
The only difference is that with fibers you can switch the context
from any function.

Don't use them if you don't actually need them. Simple.

--- PyGate Linux v1.5.17
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-06-13 15:38, Bart wrote:

On 13/06/2026 13:35, Janis Papanagnou wrote:

On 2026-06-13 12:14, tTh wrote:

On 6/13/26 12:03, Bart wrote:

Seriously? You have a language where you can literally do this:

ÿÿ #include <stdint.h>
ÿÿ int32_t int32_t;
ÿÿ int32_t = 0;

and that is just fine; just "don't do it"! In that case, we might as >>>>> well allow:

ÿÿ int int;

Can you understand how crazy the above looks from outside?

<pins>

In the case of 'int32_t' this is supposedly a core C type but it is
quite unknown to the language until you include a particular header.

Yes. That's something that I (also?) don't think is good language
design. (Many things in "C" I actually consider to be kludges and
quirks; but so what?)

Technically, the C language evolved, it wasn't designed per se.

And there are good reasons (backward compatability) for conditioning
support of the fixed size types on inclusion of <stdint.h> rather than
building them into the language. Like it or not, it cannot be changed.

--- PyGate Linux v1.5.17
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-06-22 23:24, Scott Lurndal wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-06-13 15:38, Bart wrote:

[...]

In the case of 'int32_t' this is supposedly a core C type but it is
quite unknown to the language until you include a particular header.

Yes. That's something that I (also?) don't think is good language
design. (Many things in "C" I actually consider to be kludges and
quirks; but so what?)

Technically, the C language evolved, it wasn't designed per se.

Well, yes and no. For me the _original design_ is responsible also
for a lot that was (had to be) adjusted, fixed, and extended later.

And there are good reasons (backward compatability) for conditioning
support of the fixed size types on inclusion of <stdint.h> rather than building them into the language.

Sure.

Like it or not, it cannot be changed.

That's what I'm also regularly saying. - In my longish post you may
have missed it:

You cannot fundamentally change "C" as it is; not after more than
five decades (since its birth), and also not after it had been
standardized; it just makes no sense to even start an argument on
that. - If you think it's "bad" don't use it.

Janis


--- PyGate Linux v1.5.17
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 6/18/2026 12:23 AM, Lawrence D?Oliveiro wrote:

On Thu, 18 Jun 2026 00:18:18 -0700, Chris M. Thomasson wrote:

I?m talking about preemption semantics, which are the same on POSIX
and Windows.

But for some reason the previous poster thinks that doing thread
preemption in the kernel is somehow more resource-heavy than doing the
exact same thing in userspace.

Those are different things? The kernel knows more than we do... Now
making a user land scheduler with, say, fibers is complete different
than what the kernel is doing...

--- PyGate Linux v1.5.17
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)