On 4/14/2024 11:20 PM, Bonita Montero wrote:
> Am 15.04.2024 um 07:03 schrieb Chris M. Thomasson:
>
>> On 4/14/2024 9:15 PM, Bonita Montero wrote:
>
>>> Absolutely not, but you consider a futex wake as slow.
>
>> Yes. I consider a futex notify and wake as "slow" paths.
>
> I've mentioned that a futex wake with no contenders is 1.7ns or about
> 10 clock cycles on my Zen4-CPU; that's nothing worth to think about.
>

I don't know what that futex notify is actually doing under the covers.
One impl might be faster than another. Whatever. I still consider a
futex notify to be a slow path because it denotes contention. Trying to
avoid a call into it is still rather "prudent", well according to me.
Why call a notify when we do not have to?

Am 15.04.2024 um 21:08 schrieb Chris M. Thomasson:

> I don't know what that futex notify is actually doing under the covers.

In 10 clock cycles you can't do much.

> One impl might be faster than another.

With Windows it's ony 2.7ns and with Linux 1.7ns.

Am 16.04.2024 um 06:32 schrieb Bonita Montero:
> Am 15.04.2024 um 21:08 schrieb Chris M. Thomasson:
>
>> I don't know what that futex notify is actually doing under the covers.
>
> In 10 clock cycles you can't do much.
>
>> One impl might be faster than another.
>
>
> With Windows it's ony 2.7ns and with Linux 1.7ns.

Try it yourself:

#include <iostream>
#include <atomic>
#include <chrono>

using namespace std;
using namespace chrono;

int main()
{ atomic_bool ab;
auto start = high_resolution_clock::now();
for( size_t i = 1'000'000'000; i; --i )
ab.notify_one();
cout << duration_cast<nanoseconds>( high_resolution_clock::now() -
start ).count() / 1.0e9 << endl;
}

With WSL2 on a Zen4-CPU it's only 1.2ns, i.e. seven clock cycles.

On 4/16/2024 2:31 AM, Bonita Montero wrote:
> Am 16.04.2024 um 06:32 schrieb Bonita Montero:
>> Am 15.04.2024 um 21:08 schrieb Chris M. Thomasson:
>>
>>> I don't know what that futex notify is actually doing under the covers.
>>
>> In 10 clock cycles you can't do much.
>>
>>> One impl might be faster than another.
>>
>>
>> With Windows it's ony 2.7ns and with Linux 1.7ns.
>
> Try it yourself:
>
> #include <iostream>
> #include <atomic>
> #include <chrono>
>
> using namespace std;
> using namespace chrono;
>
> int main()
> {
>     atomic_bool ab;
>     auto start = high_resolution_clock::now();
>     for( size_t i = 1'000'000'000; i; --i )
>         ab.notify_one();
>     cout << duration_cast<nanoseconds>( high_resolution_clock::now() -
> start ).count() / 1.0e9 << endl;
> }
>
> With WSL2 on a Zen4-CPU it's only 1.2ns, i.e. seven clock cycles.
>

I will, however I am working on another project right now, heavy
graphics based. Basically, I would want to see how notify_one is
actually implemented. Bust out the disassembler.

On 4/15/2024 9:32 PM, Bonita Montero wrote:
> Am 15.04.2024 um 21:08 schrieb Chris M. Thomasson:
>
>> I don't know what that futex notify is actually doing under the covers.
>
> In 10 clock cycles you can't do much.

Well, futex notify might have fast paths in and of itself. To be prudent
I would need to see how they implement it to allow a futex notify by,
every time. Fair enough?

>
>> One impl might be faster than another.
>
>
> With Windows it's ony 2.7ns and with Linux 1.7ns.

Am 16.04.2024 um 23:07 schrieb Chris M. Thomasson:

> I will, however I am working on another project right now, heavy
> graphics based. Basically, I would want to see how notify_one is
> actually implemented. Bust out the disassembler.

It will practically not matter how it is implemented if it is that fast.

On 4/17/2024 1:24 AM, Bonita Montero wrote:
> Am 16.04.2024 um 23:07 schrieb Chris M. Thomasson:
>
>> I will, however I am working on another project right now, heavy
>> graphics based. Basically, I would want to see how notify_one is
>> actually implemented. Bust out the disassembler.
>
> It will practically not matter how it is implemented if it is that fast.

It just might take an internal hashed mutex to check for contention...
Humm... I don't know until I look at it. I don't even want it to do a
CAS, or execute any membars on a "fast-path". Since I don't know what
its doing under the covers, I still think its "prudent" to try to avoid
calling into it when we do absolutely have to.

On 4/17/2024 11:48 AM, Chris M. Thomasson wrote:
> On 4/17/2024 1:24 AM, Bonita Montero wrote:
>> Am 16.04.2024 um 23:07 schrieb Chris M. Thomasson:
>>
>>> I will, however I am working on another project right now, heavy
>>> graphics based. Basically, I would want to see how notify_one is
>>> actually implemented. Bust out the disassembler.
>>
>> It will practically not matter how it is implemented if it is that fast.
>
> It just might take an internal hashed mutex to check for contention...
> Humm... I don't know until I look at it. I don't even want it to do a
> CAS, or execute any membars on a "fast-path". Since I don't know what
> its doing under the covers, I still think its "prudent" to try to avoid
> calling into it when we do absolutely have to.
^^^^^^^^^^^^^^

God damn typos! Sorry Bonita!

I still think its "prudent" to try to avoid calling into it, _except_
when we absolutely have to.

Argh! Sorry again.

Am 16.04.2024 um 23:14 schrieb Chris M. Thomasson:

> Well, futex notify might have fast paths in and of itself. To be prudent
> I would need to see how they implement it to allow a futex notify by,
> every time. Fair enough?

I'm asking myself if it would be possible to have context-switching as
most as possible in userspace. If there would be a context-switch from
one thread of a process to another thread because a timeslice expired
the kernel should send a signal to the thread and the thread does the
userspace context-switch by itself. Only if there's a context switch
to another process' thread or in kernel mode the kernel's scheduler
acts itself.
This would give the opportunity to have voluntary context switches
when doing locking much faster than trough the kernel, and voluntary
context switches usually happen with a much higher frequency that
there would be a real gain.
With Linux this would be possible trough signals and on Windows the
kernel could induce SEH-exceptions for a thread-switch.

On 4/18/24 9:12 AM, Bonita Montero wrote:
> Am 16.04.2024 um 23:14 schrieb Chris M. Thomasson:
>
>> Well, futex notify might have fast paths in and of itself. To be
>> prudent I would need to see how they implement it to allow a futex
>> notify by, every time. Fair enough?
>
> I'm asking myself if it would be possible to have context-switching as
> most as possible in userspace. If there would be a context-switch from
> one thread of a process to another thread because a timeslice expired
> the kernel should send a signal to the thread and the thread does the
> userspace context-switch by itself. Only if there's a context switch
> to another process' thread or in kernel mode the kernel's scheduler
> acts itself.
> This would give the opportunity to have voluntary context switches
> when doing locking much faster than trough the kernel, and voluntary
> context switches usually happen with a much higher frequency that
> there would be a real gain.
> With Linux this would be possible trough signals and on Windows the
> kernel could induce SEH-exceptions for a thread-switch.
>

How do you "signal" a user-thread without doing a kernel operation and a
thread switch?

Admittedly, if the kernel knows it is switching from one thread to
another in the same process it can do a lighter weight sort of
context-switch, but it still needs to deal with kernel space operations.

Am 19.04.2024 um 04:03 schrieb Richard Damon:

> How do you "signal" a user-thread without doing a kernel operation
> and a thread switch?

The signals for the involuntary userspace thread-switch would be sent
by a dedicated kernel-thread or by the timer interrupt. This would be
more expensive than a thread-switch through the timer interrupt but
as voluntary thread-switches have a much higher frequency this would
be outweighed.

> Admittedly, if the kernel knows it is switching from one thread
> to another in the same process it can do a lighter weight sort of
> context-switch, but it still needs to deal with kernel space operations.

A context switch through the kernel is always expensive. A user
-level thread switch when blocking for a lock would be much faster.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 19.04.2024 um 04:03 schrieb Richard Damon:

>> Admittedly, if the kernel knows it is switching from one thread
>> to another in the same process it can do a lighter weight sort of
>> context-switch, but it still needs to deal with kernel space operations.
>
>A context switch through the kernel is always expensive. A user
>-level thread switch when blocking for a lock would be much faster.

SVR4.2MP implemented a M-N thread model (M user threads mapped to
N kernel threads). Turned out not to work well.

Am 19.04.2024 um 15:41 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 19.04.2024 um 04:03 schrieb Richard Damon:
>
>>> Admittedly, if the kernel knows it is switching from one thread
>>> to another in the same process it can do a lighter weight sort of
>>> context-switch, but it still needs to deal with kernel space operations.
>>
>> A context switch through the kernel is always expensive. A user
>> -level thread switch when blocking for a lock would be much faster.
>
> SVR4.2MP implemented a M-N thread model (M user threads mapped to
> N kernel threads). Turned out not to work well.

The thing that I'm imaging is still 1:1 but if threads are in userspace
thread-switching would be done by the userspace.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 19.04.2024 um 15:41 schrieb Scott Lurndal:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> Am 19.04.2024 um 04:03 schrieb Richard Damon:
>>
>>>> Admittedly, if the kernel knows it is switching from one thread
>>>> to another in the same process it can do a lighter weight sort of
>>>> context-switch, but it still needs to deal with kernel space operations.
>>>
>>> A context switch through the kernel is always expensive. A user
>>> -level thread switch when blocking for a lock would be much faster.
>>
>> SVR4.2MP implemented a M-N thread model (M user threads mapped to
>> N kernel threads). Turned out not to work well.
>
>The thing that I'm imaging is still 1:1 but if threads are in userspace
>thread-switching would be done by the userspace.

Feel free to prototype it using setcontext(2), getcontext(2) and
makecontext(2).

Am 19.04.2024 um 16:48 schrieb Scott Lurndal:

> Feel free to prototype it using setcontext(2), getcontext(2) and
> makecontext(2).

I'd need the support of the kernel which should not make context
switches to another thread inside the same process if the thread
is within userspace. And the kernel should have to periodically
inject signals from the timer interrupt to userspace to make it
possible that the userspace-code does the involuntary context
-switch on its own. And I'd need synchronization-primitives like
mutexes and semaphores that would do the otherwise costly context
-switch in userspace; but that's rather easy compared to the kernel
support.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 19.04.2024 um 16:48 schrieb Scott Lurndal:
>
>> Feel free to prototype it using setcontext(2), getcontext(2) and
>> makecontext(2).
>
>I'd need the support of the kernel which should not make context
>switches to another thread inside the same process if the thread
>is within userspace. And the kernel should have to periodically
>inject signals from the timer interrupt to userspace to make it
>possible that the userspace-code does the involuntary context
>-switch on its own. And I'd need synchronization-primitives like
>mutexes and semaphores that would do the otherwise costly context
>-switch in userspace; but that's rather easy compared to the kernel
>support.

https://www.kernel.org/

Feel free to modify the kernel to your heart's content.

Am 19.04.2024 um 20:27 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 19.04.2024 um 16:48 schrieb Scott Lurndal:
>>
>>> Feel free to prototype it using setcontext(2), getcontext(2) and
>>> makecontext(2).
>>
>> I'd need the support of the kernel which should not make context
>> switches to another thread inside the same process if the thread
>> is within userspace. And the kernel should have to periodically
>> inject signals from the timer interrupt to userspace to make it
>> possible that the userspace-code does the involuntary context
>> -switch on its own. And I'd need synchronization-primitives like
>> mutexes and semaphores that would do the otherwise costly context
>> -switch in userspace; but that's rather easy compared to the kernel
>> support.
>
> https://www.kernel.org/
>
> Feel free to modify the kernel to your heart's content.

Seems you don't understand the idead and you think this isn't
possible.

On 4/19/24 12:18 AM, Bonita Montero wrote:
> Am 19.04.2024 um 04:03 schrieb Richard Damon:
>
>> How do you "signal" a user-thread without doing a kernel operation
>> and a thread switch?
>
> The signals for the involuntary userspace thread-switch would be sent
> by a dedicated kernel-thread or by the timer interrupt. This would be
> more expensive than a thread-switch through the timer interrupt but
> as voluntary thread-switches have a much higher frequency this would
> be outweighed.

TO WHAT?

Are you going to reserve a core with a dedicated thread to do this?

To "interrupt" a user thread to notify it, you would either need to
perform a context switch to save the threads previous context or make
the interrupt non-returnable. If you are going to context switch to the
notification thread, you might as well switch the the new user-thread
that you want to go to.

>
>> Admittedly, if the kernel knows it is switching from one thread
>> to another in the same process it can do a lighter weight sort of
>> context-switch, but it still needs to deal with kernel space operations.
>
> A context switch through the kernel is always expensive. A user
> -level thread switch when blocking for a lock would be much faster.

But you still had the kernal doing a context switch.

Am 20.04.2024 um 05:00 schrieb Richard Damon:
> On 4/19/24 12:18 AM, Bonita Montero wrote:
>> Am 19.04.2024 um 04:03 schrieb Richard Damon:
>>
>>> How do you "signal" a user-thread without doing a kernel operation
>>> and a thread switch?
>>
>> The signals for the involuntary userspace thread-switch would be sent
>> by a dedicated kernel-thread or by the timer interrupt. This would be
>> more expensive than a thread-switch through the timer interrupt but
>> as voluntary thread-switches have a much higher frequency this would
>> be outweighed.
>
> TO WHAT?
>
> Are you going to reserve a core with a dedicated thread to do this?

A userspace thread is scheduled on a core if there's no other thread
on that core. But if there would be other threads eligible to run on
the core they would be scheduled by a signal in userspace if their
context is also in userspace.

> To "interrupt" a user thread to notify it, you would either need to
> perform a context switch to save the threads previous context or make
> the interrupt non-returnable. If you are going to context switch to the
> notification thread, you might as well switch the the new user-thread
> that you want to go to.

You simply don't understand my idea !

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 19.04.2024 um 20:27 schrieb Scott Lurndal:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> Am 19.04.2024 um 16:48 schrieb Scott Lurndal:
>>>
>>>> Feel free to prototype it using setcontext(2), getcontext(2) and
>>>> makecontext(2).
>>>
>>> I'd need the support of the kernel which should not make context
>>> switches to another thread inside the same process if the thread
>>> is within userspace. And the kernel should have to periodically
>>> inject signals from the timer interrupt to userspace to make it
>>> possible that the userspace-code does the involuntary context
>>> -switch on its own. And I'd need synchronization-primitives like
>>> mutexes and semaphores that would do the otherwise costly context
>>> -switch in userspace; but that's rather easy compared to the kernel
>>> support.
>>
>> https://www.kernel.org/
>>
>> Feel free to modify the kernel to your heart's content.
>
>Seems you don't understand the idead and you think this isn't
>possible.
>

It seems the lack of understanding is on you. Du verstehst es nicht.

"... should not make context switches to another thread inside
the same process if the thread is within userspace".

It seems clear that the thread within userspace is completely
invisible to the kernel, thus it cannot by definition switch to it.

It's not that I don't think it is possible, I just don't think
it provides any measurable benefit for the added complexity.

Am 20.04.2024 um 17:16 schrieb Scott Lurndal:

> It seems clear that the thread within userspace is completely
> invisible to the kernel, thus it cannot by definition switch to it.

I'm not talking about userlevel-threads but the state when a thread
is in userspace-state. You lack imagination since you don't understand
my idea.