Groups > comp.lang.c++ > #122160 > unrolled thread

signalling a condvar from inside vs. signalling a condvar von outside

Started by	Bonita Montero <Bonita.Montero@gmail.com>
First post	2025-04-12 17:23 +0200
Last post	2025-04-24 23:10 +0200
Articles	20 on this page of 53 — 3 participants

Back to article view | Back to comp.lang.c++

  signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-12 17:23 +0200
    Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-12 12:33 -0700
      Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-13 17:38 +0200
        Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-13 12:32 -0700
          Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-13 22:08 +0200
            Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-13 14:40 -0700
              Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-15 11:41 +0200
                Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-15 12:07 -0700
                  Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-16 06:12 +0200
                    Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-16 15:59 -0700
                      Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-17 05:58 +0200
                        Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-16 22:26 -0700
                          Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-17 13:20 +0200
                            Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-17 10:51 -0700
                              Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-18 07:56 +0200
                                Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-18 12:42 -0700
                                  Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-18 22:05 +0200
                                    Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-19 02:25 -0700
                                      Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-19 11:29 +0200
                                        Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-19 03:10 -0700
                                          Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-19 03:12 -0700
                                          Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-19 14:09 +0200
                                            Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-19 07:34 -0700
                                              Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-19 07:35 -0700
                                              Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-19 17:24 +0200
                                                Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-19 19:33 -0700
                                    Re: signalling a condvar from inside vs. signalling a condvar von outside scott@slp53.sl.home (Scott Lurndal) - 2025-04-19 14:55 +0000
                                      Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-19 17:25 +0200
                                        Re: signalling a condvar from inside vs. signalling a condvar von outside scott@slp53.sl.home (Scott Lurndal) - 2025-04-19 22:59 +0000
                                          Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-20 06:19 +0200
                                          Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-20 06:29 +0200
                                            Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-19 22:43 -0700
                                              Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-20 07:45 +0200
                                                Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-19 22:49 -0700
                                                  Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-20 09:07 +0200
                                                    Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-20 14:17 -0700
                                          Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-20 14:18 -0700
                                            Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-21 06:55 +0200
                                              Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-21 17:28 -0700
                                                Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-22 07:16 +0200
                                                  Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-22 14:36 -0700
                                                    Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-23 07:13 +0200
                                                      Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-23 12:08 -0700
                                                        Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-24 06:30 +0200
                                                          Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-24 13:00 -0700
                                                        Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-24 19:02 +0200
                                                          Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-24 12:59 -0700
                                                            Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-24 23:11 +0200
                                                    Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-23 07:46 +0200
                                                      Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-24 13:05 -0700
                                                        Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-24 13:15 -0700
                                                          Re: signalling a condvar from inside vs. signalling a condvar von outside "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-24 13:17 -0700
                                                        Re: signalling a condvar from inside vs. signalling a condvar von outside Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-24 23:10 +0200

Page 1 of 3 [1] 2 3 Next page →

#122160 — signalling a condvar from inside vs. signalling a condvar von outside

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2025-04-12 17:23 +0200
Subject	signalling a condvar from inside vs. signalling a condvar von outside
Message-ID	<vte0g6$pmgv$1@raubtier-asyl.eternal-september.org>

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

using namespace std;

int main()
{
	struct synch_t
	{
		mutex mtx;
		bool signalled = false;
		condition_variable cv;
	};
	atomic_long nVoluntary;
	auto thr = [&]( synch_t &me, synch_t &you, auto &&toYou )
	{
		for( size_t r = 10'000; r; --r )
		{
			unique_lock lockMe( me.mtx );
			me.cv.wait( lockMe, [&] { return me.signalled; } );
			me.signalled = false;
			lockMe.unlock();
			toYou( you );
		}
		rusage ru;
		getrusage( RUSAGE_THREAD, &ru );
		nVoluntary.fetch_add( ru.ru_nvcsw );
	};
	auto doIt = [&]( char const *what, auto &&toYou )
	{
		synch_t synchA { {}, true, {} }, synchB;
		nVoluntary.store( 0, memory_order_relaxed );
		jthread
			thrA( [&]() { thr( synchA, synchB, move( toYou ) ); } ),
			thrB( [&]() { thr( synchB, synchA, move( toYou ) ); } );
		thrA.join();
		thrB.join();
		cout << what << nVoluntary.load( memory_order_relaxed ) << endl;
	};
	doIt( "inside: ", []( synch_t &synch )
		{
			lock_guard lock( synch.mtx );
			synch.signalled = true;
			synch.cv.notify_one();
		} );
	doIt( "outside: ", []( synch_t &synch )
		{
			unique_lock lock( synch.mtx );
			synch.signalled = true;
			lock.unlock();
			synch.cv.notify_one();
		} );

}

It nearly doesn't matter in terms of numbers of context switches if
you  signal a condvar from inside our outside. The above program run
on a Zen4-CPU with WSL2:

	inside: 20130
	outside: 19811

On a 28 core Skylake-CPU with Ubuntu:

	inside: 19997
	outside: 19888

[toc] | [next] | [standalone]

#122161

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2025-04-12 12:33 -0700
Message-ID	<vtef76$16guv$1@dont-email.me>
In reply to	#122160

On 4/12/2025 8:23 AM, Bonita Montero wrote:
[...]
> It nearly doesn't matter in terms of numbers of context switches if
> you  signal a condvar from inside our outside. The above program run
> on a Zen4-CPU with WSL2:
> 
>      inside: 20130
>      outside: 19811
> 
> On a 28 core Skylake-CPU with Ubuntu:
> 
>      inside: 19997
>      outside: 19888
> 

There is a scalability problem wrt signalling inside the critical 
section. Does your convdar impl use wait morphing?

[toc] | [prev] | [next] | [standalone]

#122162

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2025-04-13 17:38 +0200
Message-ID	<vtgloc$36urv$1@raubtier-asyl.eternal-september.org>
In reply to	#122161

Am 12.04.2025 um 21:33 schrieb Chris M. Thomasson:

> There is a scalability problem wrt signalling inside the critical 
> section. Does your convdar impl use wait morphing?

There's no scalability problem with that since the kernel call to
release a thread happens only when the mutex is accessible *and*
the cv is signalled.

[toc] | [prev] | [next] | [standalone]

#122163

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2025-04-13 12:32 -0700
Message-ID	<vth3gt$3j0qm$1@dont-email.me>
In reply to	#122162

On 4/13/2025 8:38 AM, Bonita Montero wrote:
> Am 12.04.2025 um 21:33 schrieb Chris M. Thomasson:
> 
>> There is a scalability problem wrt signalling inside the critical 
>> section. Does your convdar impl use wait morphing?
> 
> There's no scalability problem with that since the kernel call to
> release a thread happens only when the mutex is accessible *and*
> the cv is signalled.
> 
> 

No. When you signal a condvar while holding the lock it means that 
waiters can wake and just instantly wait on the lock. This is why wait 
morphing was created. It helps, but only so much...

[toc] | [prev] | [next] | [standalone]

#122164

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2025-04-13 22:08 +0200
Message-ID	<vth5ig$3kqh7$1@raubtier-asyl.eternal-september.org>
In reply to	#122163

Am 13.04.2025 um 21:32 schrieb Chris M. Thomasson:
> On 4/13/2025 8:38 AM, Bonita Montero wrote:
>> Am 12.04.2025 um 21:33 schrieb Chris M. Thomasson:
>>
>>> There is a scalability problem wrt signalling inside the critical 
>>> section. Does your convdar impl use wait morphing?
>>
>> There's no scalability problem with that since the kernel call to
>> release a thread happens only when the mutex is accessible *and*
>> the cv is signalled.
>>
>>
> 
> No. ...

The numer of context-switches my code shows say that there's only
one context-switchz per wait.

>When you signal a condvar while holding the lock it means that  waiters can wake and just instantly wait on the lock. This is why wait 
> morphing was created. It helps, but only so much...


idiot.

[toc] | [prev] | [next] | [standalone]

#122165

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2025-04-13 14:40 -0700
Message-ID	<vthb0p$3p9fh$1@dont-email.me>
In reply to	#122164

On 4/13/2025 1:08 PM, Bonita Montero wrote:
> Am 13.04.2025 um 21:32 schrieb Chris M. Thomasson:
>> On 4/13/2025 8:38 AM, Bonita Montero wrote:
>>> Am 12.04.2025 um 21:33 schrieb Chris M. Thomasson:
>>>
>>>> There is a scalability problem wrt signalling inside the critical 
>>>> section. Does your convdar impl use wait morphing?
>>>
>>> There's no scalability problem with that since the kernel call to
>>> release a thread happens only when the mutex is accessible *and*
>>> the cv is signalled.
>>>
>>>
>>
>> No. ...
> 
> The numer of context-switches my code shows say that there's only
> one context-switchz per wait.

You code is hard to read. Sigh. Signalling while locked or unlocked was 
an old debate. Think of signalling while holding the lock. A thread gets 
woken and immediately sees that the lock is held. Oh well. Wait morphing 
can help with that. However, signal outside when you can...


>> When you signal a condvar while holding the lock it means that  
>> waiters can wake and just instantly wait on the lock. This is why wait 
>> morphing was created. It helps, but only so much...
> 
> 
> idiot.
> 

Whatever.

[toc] | [prev] | [next] | [standalone]

#122169

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2025-04-15 11:41 +0200
Message-ID	<vtl9ii$3dqu3$1@raubtier-asyl.eternal-september.org>
In reply to	#122165

Am 13.04.2025 um 23:40 schrieb Chris M. Thomasson:

> You code is hard to read. ...

The code is beautiful.

> Signalling while locked or unlocked was an old debate. Think of signalling
> while holding the lock. A thread gets woken and immediately sees that the
> lock is held. Oh well. Wait morphing  can help with that. However, signal
> outside when you can...

The number of context-switches determined via getrusage() is twice per
loop iteration, i.e. on switch to the thread and one switch from the
thread; so everything is optimal with glibc.

[toc] | [prev] | [next] | [standalone]

#122170

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2025-04-15 12:07 -0700
Message-ID	<vtmapb$bjcc$1@dont-email.me>
In reply to	#122169

On 4/15/2025 2:41 AM, Bonita Montero wrote:
> Am 13.04.2025 um 23:40 schrieb Chris M. Thomasson:
> 
>> You code is hard to read. ...
> 
> The code is beautiful.

I can understand it, but, well, shit happens. I would not say it's 
beautiful... But, that is just me. Again, shit happens.

>> Signalling while locked or unlocked was an old debate. Think of 
>> signalling
>> while holding the lock. A thread gets woken and immediately sees that the
>> lock is held. Oh well. Wait morphing  can help with that. However, signal
>> outside when you can...
> 
> The number of context-switches determined via getrusage() is twice per
> loop iteration, i.e. on switch to the thread and one switch from the
> thread; so everything is optimal with glibc.

In real applications there is generally more going on in those critical 
sections vs your test... Well, I have seen some horror shows in my life.

Again, think of a scenario where the lock is held. The thread signals... 
Another thread wakes up and has to instantly block on a wait morphing 
queue in the kernel. This is not "ideal". A signal outside of the mutex 
can be beneficial. Signalling outside can give a signaled thread a 
possible fast-path into the critical section, completely eliminating the 
need for kernel interaction. Now, an adaptive mutex can try to help with 
this via limited spinning... However, try to signal outside when you can.

[toc] | [prev] | [next] | [standalone]

#122173

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2025-04-16 06:12 +0200
Message-ID	<vtnam3$1c6fn$1@raubtier-asyl.eternal-september.org>
In reply to	#122170

Am 15.04.2025 um 21:07 schrieb Chris M. Thomasson:

> In real applications there is generally more going on in those critical 
> sections vs your test... Well, I have seen some horror shows in my life.
> 
> Again, think of a scenario where the lock is held. The thread signals... 
> Another thread wakes up and has to instantly block on a wait morphing 
> queue in the kernel.

Not with glibc.

[toc] | [prev] | [next] | [standalone]

#122179

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2025-04-16 15:59 -0700
Message-ID	<vtpcnt$384n4$1@dont-email.me>
In reply to	#122173

On 4/15/2025 9:12 PM, Bonita Montero wrote:
> Am 15.04.2025 um 21:07 schrieb Chris M. Thomasson:
> 
>> In real applications there is generally more going on in those 
>> critical sections vs your test... Well, I have seen some horror shows 
>> in my life.
>>
>> Again, think of a scenario where the lock is held. The thread 
>> signals... Another thread wakes up and has to instantly block on a 
>> wait morphing queue in the kernel.
> 
> Not with glibc.
> 

Sigh. I would need to see how glibc works internally. But that is 
besides the point. Try to signal/broadcast outside when possible.

[toc] | [prev] | [next] | [standalone]

#122180

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2025-04-17 05:58 +0200
Message-ID	<vtpu86$3qnsh$1@raubtier-asyl.eternal-september.org>
In reply to	#122179

Am 17.04.2025 um 00:59 schrieb Chris M. Thomasson:

> Sigh. I would need to see how glibc works internally. But that is 
> besides the point. Try to signal/broadcast outside when possible.

As I've shown that's not necessary with glibc; the number of context
switches and the CPU time is nearly the same for both cases.

[toc] | [prev] | [next] | [standalone]

#122181

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2025-04-16 22:26 -0700
Message-ID	<vtq3dt$3vg77$1@dont-email.me>
In reply to	#122180

On 4/16/2025 8:58 PM, Bonita Montero wrote:
> Am 17.04.2025 um 00:59 schrieb Chris M. Thomasson:
> 
>> Sigh. I would need to see how glibc works internally. But that is 
>> besides the point. Try to signal/broadcast outside when possible.
> 
> As I've shown that's not necessary with glibc; the number of context
> switches and the CPU time is nearly the same for both cases.
> 

So, signal wherever you like! I don't care. I will signal outside when I 
can. That's that.

[toc] | [prev] | [next] | [standalone]

#122183

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2025-04-17 13:20 +0200
Message-ID	<vtqo57$hi7r$1@raubtier-asyl.eternal-september.org>
In reply to	#122181

Am 17.04.2025 um 07:26 schrieb Chris M. Thomasson:

> So, signal wherever you like! I don't care. I will signal outside when I 
> can. That's that.

Of course you can, but it doesn't matter if you signal from outside or
inside.

[toc] | [prev] | [next] | [standalone]

#122186

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2025-04-17 10:51 -0700
Message-ID	<vtrf3u$15mgp$1@dont-email.me>
In reply to	#122183

On 4/17/2025 4:20 AM, Bonita Montero wrote:
> Am 17.04.2025 um 07:26 schrieb Chris M. Thomasson:
> 
>> So, signal wherever you like! I don't care. I will signal outside when 
>> I can. That's that.
> 
> Of course you can, but it doesn't matter if you signal from outside or
> inside.
> 

The only thing I can say is that signalling, especially broadcasting, 
from the outside is ideal no matter what lib's you are using. If the lib 
has a very clever wait morph, so be it. Were are talking about scaling 
mutexes, so, well, ugggh.

[toc] | [prev] | [next] | [standalone]

#122188

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2025-04-18 07:56 +0200
Message-ID	<vtsph1$2d55o$1@raubtier-asyl.eternal-september.org>
In reply to	#122186

Am 17.04.2025 um 19:51 schrieb Chris M. Thomasson:

> The only thing I can say is that signalling, especially broadcasting, 
> from the outside is ideal no matter what lib's you are using. ..

With broadcasting it also doesn't matter if you broadcast from inside
or outside.

[toc] | [prev] | [next] | [standalone]

#122189

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2025-04-18 12:42 -0700
Message-ID	<vtu9un$3mhje$1@dont-email.me>
In reply to	#122188

On 4/17/2025 10:56 PM, Bonita Montero wrote:
> Am 17.04.2025 um 19:51 schrieb Chris M. Thomasson:
> 
>> The only thing I can say is that signalling, especially broadcasting, 
>> from the outside is ideal no matter what lib's you are using. ..
> 
> With broadcasting it also doesn't matter if you broadcast from inside
> or outside.
> 

We have to agree to disagree? Fair enough?

[toc] | [prev] | [next] | [standalone]

#122190

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2025-04-18 22:05 +0200
Message-ID	<vtub8i$3o27s$1@raubtier-asyl.eternal-september.org>
In reply to	#122189

Am 18.04.2025 um 21:42 schrieb Chris M. Thomasson:
> On 4/17/2025 10:56 PM, Bonita Montero wrote:
>> Am 17.04.2025 um 19:51 schrieb Chris M. Thomasson:
>>
>>> The only thing I can say is that signalling, especially broadcasting, 
>>> from the outside is ideal no matter what lib's you are using. ..
>>
>> With broadcasting it also doesn't matter if you broadcast from inside
>> or outside.
>>
> 
> We have to agree to disagree? Fair enough?

But there's one interesting fact to learn at last: broadcasting is more
efficient than unicasting. That's while I have a wait -counter with my
thread-queue and depending on how much items I've inserted in one run
I broadcast (N >= waiting) or I multiple times have a unicast. A n-cast
would be nice to have with that.

template<typename Entity>
template<std::forward_iterator ForwardIt>
void thread_queue<Entity>::enqueue( ForwardIt &begin, ForwardIt end )
	requires std::convertible_to<std::iter_value_t<ForwardIt>, Entity>
{
	using namespace std;
	// return if there's nothing to do
	if( begin == end ) [[unlikely]]
		return;
	lock_guard lock( m_mtx );
	// throw if there are emergencies
	if( m_producerEmergencies.size() ) [[unlikely]]
		throw thread_queue_emergency( *this, m_producerEmergencies );
	// number of items pushed so far
	size_t n = 0;
	// notify threads while unrolling
	defer notify( [&]
		{
			// no threads to be awakened ?
			if( !m_nWaiting )
				// yes: nothing to do
				return;
			// more items pushed than waiting ?
			if( n >= m_nWaiting )
				// yes: notify them all (doesn't throw)
				m_cv.notify_all();
			else
				// no: notify n threads
				do
					m_cv.notify_one();
				while( --n );
		} );
	do [[likely]]
	{
		// push and increment n
		m_queue.emplace_back( move( *begin ) );
		++n;
	} while( ++begin != end );
}

defer is sth. like experimental::scope_exit.
Usually there are more items inserted as threads listening so that
I could do a broadcast, which is much more efficient.

[toc] | [prev] | [next] | [standalone]

#122191

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2025-04-19 02:25 -0700
Message-ID	<vtvq5i$149vk$1@dont-email.me>
In reply to	#122190

On 4/18/2025 1:05 PM, Bonita Montero wrote:
> Am 18.04.2025 um 21:42 schrieb Chris M. Thomasson:
>> On 4/17/2025 10:56 PM, Bonita Montero wrote:
>>> Am 17.04.2025 um 19:51 schrieb Chris M. Thomasson:
>>>
>>>> The only thing I can say is that signalling, especially 
>>>> broadcasting, from the outside is ideal no matter what lib's you are 
>>>> using. ..
>>>
>>> With broadcasting it also doesn't matter if you broadcast from inside
>>> or outside.
>>>
>>
>> We have to agree to disagree? Fair enough?
> 
> But there's one interesting fact to learn at last: broadcasting is more
> efficient than unicasting.

Ugggg... Only broadcast when you absolutely have to! Not willy nilly. 
Argh! Anyway...

[...]

[toc] | [prev] | [next] | [standalone]

#122192

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2025-04-19 11:29 +0200
Message-ID	<vtvqd0$149h7$2@raubtier-asyl.eternal-september.org>
In reply to	#122191

Am 19.04.2025 um 11:25 schrieb Chris M. Thomasson:

>> But there's one interesting fact to learn at last: broadcasting is more
>> efficient than unicasting.

> Ugggg... Only broadcast when you absolutely have to! Not willy nilly. 
> Argh! Anyway...

That's not true. As you can see from my source I'm broadcasting when
there are more or equal elements than waiting threads. That's much
more efficient.
And I don't wanted to say that broadcasting should be preferred
mostly but I've measured with Windows and Linux that if broadcasting
is eligible in the mentioned way it's more efficient even when there's
only a single waiting threads.
You should have dropped your objection if you first read my source.

[toc] | [prev] | [next] | [standalone]

#122193

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2025-04-19 03:10 -0700
Message-ID	<vtvsq4$172j8$1@dont-email.me>
In reply to	#122192

On 4/19/2025 2:29 AM, Bonita Montero wrote:
> Am 19.04.2025 um 11:25 schrieb Chris M. Thomasson:
> 
>>> But there's one interesting fact to learn at last: broadcasting is more
>>> efficient than unicasting.
> 
>> Ugggg... Only broadcast when you absolutely have to! Not willy nilly. 
>> Argh! Anyway...
> 
> That's not true. 

Uggg... A broadcast is a special case. Well, when would you use a 
broadcast vs a single signal? Ugggg...



> As you can see from my source I'm broadcasting when
> there are more or equal elements than waiting threads. That's much
> more efficient.
> And I don't wanted to say that broadcasting should be preferred
> mostly but I've measured with Windows and Linux that if broadcasting
> is eligible in the mentioned way it's more efficient even when there's
> only a single waiting threads.
> You should have dropped your objection if you first read my source.
>

[toc] | [prev] | [next] | [standalone]

Page 1 of 3 [1] 2 3 Next page →

csiph-web

signalling a condvar from inside vs. signalling a condvar von outside

Contents

#122160 — signalling a condvar from inside vs. signalling a condvar von outside

#122161

#122162

#122163

#122164

#122165

#122169

#122170

#122173

#122179

#122180

#122181

#122183

#122186

#122188

#122189

#122190

#122191

#122192

#122193