Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

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

counting_semaphore question

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

Contents

  counting_semaphore question Muttley@dastardlyhq.com - 2024-09-11 10:15 +0000
    Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-11 13:48 +0200
      Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-11 12:03 +0000
        Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-11 14:10 +0200
          Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-11 12:29 +0000
            Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-11 15:54 +0200
              Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-11 14:12 +0000
            Re: counting_semaphore question David Brown <david.brown@hesbynett.no> - 2024-09-11 16:23 +0200
              Re: counting_semaphore question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-16 14:22 -0700
                Re: counting_semaphore question David Brown <david.brown@hesbynett.no> - 2024-09-17 09:22 +0200
                  Re: counting_semaphore question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-17 11:56 -0700
                    Re: counting_semaphore question David Brown <david.brown@hesbynett.no> - 2024-09-18 09:32 +0200
                      Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-19 12:57 +0200
                        Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-19 13:01 +0200
                        Re: counting_semaphore question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-19 12:09 -0700
                        Re: counting_semaphore question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-19 13:27 -0700
                          Re: counting_semaphore question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-19 13:30 -0700
            Re: counting_semaphore question Ben Bacarisse <ben@bsb.me.uk> - 2024-09-12 11:25 +0100
              Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-12 11:00 +0000
                Re: counting_semaphore question Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-12 07:34 -0700
                  Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-12 14:53 +0000
                    Re: counting_semaphore question David Brown <david.brown@hesbynett.no> - 2024-09-13 08:39 +0200
                      Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-13 07:26 +0000
                        Re: counting_semaphore question David Brown <david.brown@hesbynett.no> - 2024-09-13 12:54 +0200
                          Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-13 13:21 +0000
                            Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-13 15:29 +0200
                              Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-13 13:41 +0000
                              Re: counting_semaphore question David Brown <david.brown@hesbynett.no> - 2024-09-15 17:33 +0200
                            Re: counting_semaphore question David Brown <david.brown@hesbynett.no> - 2024-09-13 16:46 +0200
                              Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-13 14:59 +0000
                    Re: counting_semaphore question Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-13 07:43 -0700
          Re: counting_semaphore question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-11 13:51 -0700
            Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-12 04:21 +0200
              Re: counting_semaphore question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-12 11:57 -0700
                Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-13 14:29 +0200
                  Re: counting_semaphore question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-13 12:44 -0700
                    Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-14 01:43 +0200
                      Re: counting_semaphore question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-13 22:21 -0700
                        Re: counting_semaphore question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-14 12:07 -0700
                      Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-14 09:18 +0000
                        Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-14 11:40 +0200
                          Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-14 10:58 +0000
                            Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-14 13:15 +0200
                              Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-14 15:13 +0000
                                Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-14 17:26 +0200
                                  Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-14 15:48 +0000
                                    Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-14 17:50 +0200
                                      Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-14 15:55 +0000
                                        Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-14 17:57 +0200
                                          Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-15 09:05 +0000
                                            Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-15 11:48 +0200
                                              Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-15 09:52 +0000
                                                Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-15 14:50 +0200
                                                  Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-15 15:28 +0000
                                                    Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-16 05:02 +0200
                                                  Re: counting_semaphore question scott@slp53.sl.home (Scott Lurndal) - 2024-09-15 16:27 +0000
                                              Re: counting_semaphore question scott@slp53.sl.home (Scott Lurndal) - 2024-09-15 16:26 +0000
                              Re: counting_semaphore question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-14 12:12 -0700
                                Re: counting_semaphore question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-14 17:21 -0700
                                Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-15 07:11 +0200
                                  Re: counting_semaphore question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-14 22:20 -0700
                                    Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-15 09:35 +0200
                                      Re: counting_semaphore question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-15 12:59 -0700
                                        Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-16 05:04 +0200
                                          Re: counting_semaphore question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-16 13:30 -0700
                          Re: counting_semaphore question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-14 12:09 -0700
    Re: counting_semaphore question Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-11 07:37 -0700
      Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-11 15:03 +0000
        Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-11 17:27 +0200
          Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-11 16:04 +0000
            Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-11 18:16 +0200
              Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-11 18:16 +0000
                Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-12 04:20 +0200
            Re: counting_semaphore question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-12 13:00 -0700
        Re: counting_semaphore question Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-11 20:56 -0700
          Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-12 07:43 +0000
            Re: counting_semaphore question David Brown <david.brown@hesbynett.no> - 2024-09-12 13:30 +0200
              Re: counting_semaphore question Muttley@dastardlyhq.com - 2024-09-12 14:48 +0000
            Re: counting_semaphore question Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-12 15:38 +0200
            Re: counting_semaphore question Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-12 07:05 -0700

Page 4 of 4 — ← Prev page 1 2 3 [4]

#120077

On 9/14/2024 10:11 PM, Bonita Montero wrote:
> Am 14.09.2024 um 21:12 schrieb Chris M. Thomasson:
> 
>> You have to think outside the box for a moment... :^) There are 
>> interesting ways to turn lock/wait/obstruction-free algorithms into 
>> ones that can wait on conditions. This gives them lock/wait free fast 
>> paths. The slow paths (waiting in kernel, signalling/broadcasting) are 
>> only hit on certain conditions.
> 
> If there's a slow path with a lock-free algorithm it's not lock-free
> any more.

So? The point is that the fast-paths will be lock-free and the slow 
paths can allow a thread to wait if it wants to on certain conditions. 
So, its pretty nice.

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

#120078

Am 15.09.2024 um 07:20 schrieb Chris M. Thomasson:

> So? The point is that the fast-paths will be lock-free and the slow 
> paths can allow a thread to wait if it wants to on certain conditions. 
> So, its pretty nice.

Then that's sham to call it lock-free if there is a slow path.

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

#120088

On 9/15/2024 12:35 AM, Bonita Montero wrote:
> Am 15.09.2024 um 07:20 schrieb Chris M. Thomasson:
> 
>> So? The point is that the fast-paths will be lock-free and the slow 
>> paths can allow a thread to wait if it wants to on certain conditions. 
>> So, its pretty nice.
> 
> Then that's sham to call it lock-free if there is a slow path.
> 

Humm... It seems like you missed my point. Think of an eventcount. It 
turns the lock-free algorithm into a "thing" that has lock-free fast 
paths. A thread can choose to wait if it wants to. Wait on certain 
conditions if it wants to, ect...

Be sure to keep in mind that a thread can always use a try_pop() (poll, 
whatever)... Or, it can choose to wait on an eventcount. Say if 5 
try_pop()'s fail in a row, it chooses to wait... This is akin to the 
logic of so-called adaptive mutexes... They will spin in user-space a 
"couple" of times to avoid a wait in the kernel... This is a way to 
avoid a "really" slow path (wait in kernel), so to speak.

Besides waits, there is another "class" of slow paths. Keep in mind that 
a slow path can be signalling or broadcasting, waiting aside for a moment...

;^)

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

#120092

Am 15.09.2024 um 21:59 schrieb Chris M. Thomasson:
> On 9/15/2024 12:35 AM, Bonita Montero wrote:
>> Am 15.09.2024 um 07:20 schrieb Chris M. Thomasson:
>>
>>> So? The point is that the fast-paths will be lock-free and the slow 
>>> paths can allow a thread to wait if it wants to on certain 
>>> conditions. So, its pretty nice.
>>
>> Then that's sham to call it lock-free if there is a slow path.
>>
> 
> Humm... It seems like you missed my point. ..

A lock-free algorithm hasn't a slow path.

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

#120105

On 9/15/2024 8:04 PM, Bonita Montero wrote:
> Am 15.09.2024 um 21:59 schrieb Chris M. Thomasson:
>> On 9/15/2024 12:35 AM, Bonita Montero wrote:
>>> Am 15.09.2024 um 07:20 schrieb Chris M. Thomasson:
>>>
>>>> So? The point is that the fast-paths will be lock-free and the slow 
>>>> paths can allow a thread to wait if it wants to on certain 
>>>> conditions. So, its pretty nice.
>>>
>>> Then that's sham to call it lock-free if there is a slow path.
>>>
>>
>> Humm... It seems like you missed my point. ..
> 
> A lock-free algorithm hasn't a slow path.
> 

You need to think of "combining" an existing lock-free algorithm with 
the ability to be able to actually wait, say on queue empty 
conditions... Does it make it not always lock-free anymore? Yes. Does it 
make it sometimes lock-free wrt striving to hit fast-paths, yup... Does 
it give a thread the ability to choose to wait or try a couple of times 
and possibly do something else? Yup. Actually, I wrote about that last 
pattern a while back wrt using try_lock on a mutex. The gist was, why 
wait when we can try to do something else...? It's an interesting 
pattern that not that hard to learn for sure.

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

#120070

On 9/14/2024 2:40 AM, Bonita Montero wrote:
> Am 14.09.2024 um 11:18 schrieb Muttley@dastardlyhq.com:
>> On Sat, 14 Sep 2024 01:43:26 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> gabbled:
>>> Am 13.09.2024 um 21:44 schrieb Chris M. Thomasson:
>>>
>>>> I am talking about a condvar/mutex based queue vs a lock-free, or 
>>>> even "mostly" wait-free queue under heavy contention... Which one is 
>>>> going to be more efficient?
>>>
>>> Lock-free queues are inefficient because they've to be polled.
>>
>> Everything has to be polled at some level except hardware interrupt based
>> code.
> 
> If the queue is empty CPU-time is usually handed voluntary to
> another thread - not with a lock-free-queue.
> 

Did you ever think of using the lock-free queue along with something 
that can allow it to wait on certain conditions? Several solutions are 
out there...

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

#120022

On 09/11/24 3:15 AM, Muttley@dastardlyhq.com wrote:
> I've been looking at counting_semaphore and it looks useful but something
> that doesn't seem to be properly explained anywhere is the template
> parameter value. eg you can do:
> 
> std::counting_semaphore sem(2)
> 
> which will let a max of 2 threads into the protected block at a time or:

No, there's nothing "max" about that 2 here. 2 means that the semaphore 
will be created with 2 available "permissions to enter" (permissions to 
`acquire()`) initially. The number of available "permissions" can be 
increased by calling `release()` after creating the semaphore. Call 
`release()` 3 more times on our semaphore right away, and the initial 2 
will increase to 5. So, 2 is not "max".

The "max" is set by the template parameter `LeastMaxValue`.

> I don't understand what the '10' will do. Its returned by the max()
> method but whats its purpose since if its the maximum possible threads
> you could have in the protected block it makes no sense because you can't
> change that value after creation as far as I can see.

The purpose of the template `LeastMaxValue` parameter is to let the 
implementation choose the best representation for the internal counter. 
Platforms will probably strive to use its native atomic types to 
represent the counter. But if you supply `LeastMaxValue` that's too 
large to fit into any atomic type, the implementation will be forced to 
switch to another approach to ensure the semaphore works properly.

-- 
Best regards,
Andrey

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

#120023

On Wed, 11 Sep 2024 07:37:13 -0700
Andrey Tarasevich <andreytarasevich@hotmail.com> boringly babbled:
>On 09/11/24 3:15 AM, Muttley@dastardlyhq.com wrote:
>> I've been looking at counting_semaphore and it looks useful but something
>> that doesn't seem to be properly explained anywhere is the template
>> parameter value. eg you can do:
>> 
>> std::counting_semaphore sem(2)
>> 
>> which will let a max of 2 threads into the protected block at a time or:
>
>No, there's nothing "max" about that 2 here. 2 means that the semaphore 
>will be created with 2 available "permissions to enter" (permissions to 
>`acquire()`) initially. The number of available "permissions" can be 
>increased by calling `release()` after creating the semaphore. Call 
>`release()` 3 more times on our semaphore right away, and the initial 2 
>will increase to 5. So, 2 is not "max".
>
>The "max" is set by the template parameter `LeastMaxValue`.

It seems I'm not the only one getting confused here. If I write:

std::counting_semaphore<10> sem(2)

then the semaphore can only be aquired TWO times, not 10. I don't understand
what the 10 is supposed to do as changing the 10 to 0,1 or 1000 makes no 
difference whatsoever to how many times acquire() can be called before 
release() is called in the tests I've done.

>> I don't understand what the '10' will do. Its returned by the max()
>> method but whats its purpose since if its the maximum possible threads
>> you could have in the protected block it makes no sense because you can't
>> change that value after creation as far as I can see.
>
>The purpose of the template `LeastMaxValue` parameter is to let the 
>implementation choose the best representation for the internal counter. 

Huh?

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

#120024

Am 11.09.2024 um 17:03 schrieb Muttley@dastardlyhq.com:
> On Wed, 11 Sep 2024 07:37:13 -0700
> Andrey Tarasevich <andreytarasevich@hotmail.com> boringly babbled:
>> On 09/11/24 3:15 AM, Muttley@dastardlyhq.com wrote:
>>> I've been looking at counting_semaphore and it looks useful but something
>>> that doesn't seem to be properly explained anywhere is the template
>>> parameter value. eg you can do:
>>>
>>> std::counting_semaphore sem(2)
>>>
>>> which will let a max of 2 threads into the protected block at a time or:
>>
>> No, there's nothing "max" about that 2 here. 2 means that the semaphore
>> will be created with 2 available "permissions to enter" (permissions to
>> `acquire()`) initially. The number of available "permissions" can be
>> increased by calling `release()` after creating the semaphore. Call
>> `release()` 3 more times on our semaphore right away, and the initial 2
>> will increase to 5. So, 2 is not "max".
>>
>> The "max" is set by the template parameter `LeastMaxValue`.
> 
> It seems I'm not the only one getting confused here. If I write:
> 
> std::counting_semaphore<10> sem(2)
> 
> then the semaphore can only be aquired TWO times, not 10. I don't understand
> what the 10 is supposed to do as changing the 10 to 0,1 or 1000 makes no
> difference whatsoever to how many times acquire() can be called before
> release() is called in the tests I've done.

10 is the maximum count the semaphore is allowed to reach, therefore 
binary_semaphore, which is an alias-template to counting_semaphore<1>,
has a maximum count of one.

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

#120025

On Wed, 11 Sep 2024 17:27:17 +0200
Bonita Montero <Bonita.Montero@gmail.com> boringly babbled:
>Am 11.09.2024 um 17:03 schrieb Muttley@dastardlyhq.com:
>> On Wed, 11 Sep 2024 07:37:13 -0700
>> Andrey Tarasevich <andreytarasevich@hotmail.com> boringly babbled:
>>> On 09/11/24 3:15 AM, Muttley@dastardlyhq.com wrote:
>>>> I've been looking at counting_semaphore and it looks useful but something
>>>> that doesn't seem to be properly explained anywhere is the template
>>>> parameter value. eg you can do:
>>>>
>>>> std::counting_semaphore sem(2)
>>>>
>>>> which will let a max of 2 threads into the protected block at a time or:
>>>
>>> No, there's nothing "max" about that 2 here. 2 means that the semaphore
>>> will be created with 2 available "permissions to enter" (permissions to
>>> `acquire()`) initially. The number of available "permissions" can be
>>> increased by calling `release()` after creating the semaphore. Call
>>> `release()` 3 more times on our semaphore right away, and the initial 2
>>> will increase to 5. So, 2 is not "max".
>>>
>>> The "max" is set by the template parameter `LeastMaxValue`.
>> 
>> It seems I'm not the only one getting confused here. If I write:
>> 
>> std::counting_semaphore<10> sem(2)
>> 
>> then the semaphore can only be aquired TWO times, not 10. I don't understand
>> what the 10 is supposed to do as changing the 10 to 0,1 or 1000 makes no
>> difference whatsoever to how many times acquire() can be called before
>> release() is called in the tests I've done.
>
>10 is the maximum count the semaphore is allowed to reach, therefore 
>binary_semaphore, which is an alias-template to counting_semaphore<1>,
>has a maximum count of one.

We're going around in circles. Instead of reading the man page how about
trying some code. How many times to you think this loop will run before it
hangs? 100 or 2?

#include <stdio.h>
#include <semaphore>

std::counting_semaphore<100> sem(2);

int main()
{
        for(int i=0;;++i)
        {
                sem.acquire();
                printf("Acquired %d\n",i);
        }
        return 0;
}

Answer: 2

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

#120026

Am 11.09.2024 um 18:04 schrieb Muttley@dastardlyhq.com:

> We're going around in circles. Instead of reading the man page how about
> trying some code. How many times to you think this loop will run before it
> hangs? 100 or 2?
> 
> #include <stdio.h>
> #include <semaphore>
> 
> std::counting_semaphore<100> sem(2);
> 
> int main()
> {
>          for(int i=0;;++i)
>          {
>                  sem.acquire();
>                  printf("Acquired %d\n",i);
>          }
>          return 0;
> }
> 
> Answer: 2
> 

There's nothing wrong with what I said. Once the semaphore is created
its maximum count isn't relevant any more. The return statement isn't
necessary since after two turns the loop is blocked by acquire(). Don't
care for semaphores, you'd need them only in special cases. For locking
shared resources a mutex is sufficient and for produver-consumer-pat-
terns a mutex along with a condition variable is optimal.
Java has lived a long time without semaphores but just with monitors
(a more efficient glue of a mutex and a condvar) and the semaphore
that was introduced later is almost never used.

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

#120027

On Wed, 11 Sep 2024 18:16:11 +0200
Bonita Montero <Bonita.Montero@gmail.com> boringly babbled:
>Am 11.09.2024 um 18:04 schrieb Muttley@dastardlyhq.com:
>
>> We're going around in circles. Instead of reading the man page how about
>> trying some code. How many times to you think this loop will run before it
>> hangs? 100 or 2?
>> 
>> #include <stdio.h>
>> #include <semaphore>
>> 
>> std::counting_semaphore<100> sem(2);
>> 
>> int main()
>> {
>>          for(int i=0;;++i)
>>          {
>>                  sem.acquire();
>>                  printf("Acquired %d\n",i);
>>          }
>>          return 0;
>> }
>> 
>> Answer: 2
>> 
>
>There's nothing wrong with what I said. Once the semaphore is created
>its maximum count isn't relevant any more. The return statement isn't

You're making zero sense. Maybe just admit you don't know what the template 
parameter is for, which also seems to be the case for the people who wrote the 
documentation for it.

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

#120029

Am 11.09.2024 um 20:16 schrieb Muttley@dastardlyhq.com:

> You're making zero sense. Maybe just admit you don't know what the template
> parameter is for, which also seems to be the case for the people who wrote the
> documentation for it.

The template parameter is the maximum release count as I've already
said. Beyond that you'vw got undefined behaviour.

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

#120042

On 9/11/2024 9:04 AM, Muttley@dastardlyhq.com wrote:
> On Wed, 11 Sep 2024 17:27:17 +0200
> Bonita Montero <Bonita.Montero@gmail.com> boringly babbled:
>> Am 11.09.2024 um 17:03 schrieb Muttley@dastardlyhq.com:
>>> On Wed, 11 Sep 2024 07:37:13 -0700
>>> Andrey Tarasevich <andreytarasevich@hotmail.com> boringly babbled:
>>>> On 09/11/24 3:15 AM, Muttley@dastardlyhq.com wrote:
>>>>> I've been looking at counting_semaphore and it looks useful but something
>>>>> that doesn't seem to be properly explained anywhere is the template
>>>>> parameter value. eg you can do:
>>>>>
>>>>> std::counting_semaphore sem(2)
>>>>>
>>>>> which will let a max of 2 threads into the protected block at a time or:
>>>>
>>>> No, there's nothing "max" about that 2 here. 2 means that the semaphore
>>>> will be created with 2 available "permissions to enter" (permissions to
>>>> `acquire()`) initially. The number of available "permissions" can be
>>>> increased by calling `release()` after creating the semaphore. Call
>>>> `release()` 3 more times on our semaphore right away, and the initial 2
>>>> will increase to 5. So, 2 is not "max".
>>>>
>>>> The "max" is set by the template parameter `LeastMaxValue`.
>>>
>>> It seems I'm not the only one getting confused here. If I write:
>>>
>>> std::counting_semaphore<10> sem(2)
>>>
>>> then the semaphore can only be aquired TWO times, not 10. I don't understand
>>> what the 10 is supposed to do as changing the 10 to 0,1 or 1000 makes no
>>> difference whatsoever to how many times acquire() can be called before
>>> release() is called in the tests I've done.
>>
>> 10 is the maximum count the semaphore is allowed to reach, therefore
>> binary_semaphore, which is an alias-template to counting_semaphore<1>,
>> has a maximum count of one.
> 
> We're going around in circles. Instead of reading the man page how about
> trying some code. How many times to you think this loop will run before it
> hangs? 100 or 2?
> 
> #include <stdio.h>
> #include <semaphore>
> 
> std::counting_semaphore<100> sem(2);
> 
> int main()
> {
>          for(int i=0;;++i)
>          {
>                  sem.acquire();
>                  printf("Acquired %d\n",i);
>          }
>          return 0;
> }
> 
> Answer: 2
> 


Afaict, you set the initial state of the semaphore to two. Therefore 
acquire will block (actually deadlock here) after two calls as in your 
test code...

https://en.cppreference.com/w/cpp/thread/counting_semaphore
______________
As its name indicates, the LeastMaxValue is the minimum max value, not 
the actual max value. Thus max() can yield a number larger than 
LeastMaxValue.
______________

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

#120031

On 09/11/24 8:03 AM, Muttley@dastardlyhq.com wrote:
> On Wed, 11 Sep 2024 07:37:13 -0700
> Andrey Tarasevich <andreytarasevich@hotmail.com> boringly babbled:
>> On 09/11/24 3:15 AM, Muttley@dastardlyhq.com wrote:
>>> I've been looking at counting_semaphore and it looks useful but something
>>> that doesn't seem to be properly explained anywhere is the template
>>> parameter value. eg you can do:
>>>
>>> std::counting_semaphore sem(2)
>>>
>>> which will let a max of 2 threads into the protected block at a time or:
>>
>> No, there's nothing "max" about that 2 here. 2 means that the semaphore
>> will be created with 2 available "permissions to enter" (permissions to
>> `acquire()`) initially. The number of available "permissions" can be
>> increased by calling `release()` after creating the semaphore. Call
>> `release()` 3 more times on our semaphore right away, and the initial 2
>> will increase to 5. So, 2 is not "max".
>>
>> The "max" is set by the template parameter `LeastMaxValue`.
> 
> It seems I'm not the only one getting confused here. If I write:
> 
> std::counting_semaphore<10> sem(2)
> 
> then the semaphore can only be aquired TWO times, not 10. 

Are you trying to troll people or what?

If you write

    std::counting_semaphore<10> sem(2);

then the semaphore can be acquired 2 times. But it can also be released 
instead at least 8 times, after which it can be acquired 10 times.

See the math? 2 + 8 = 10?

The 10 is the "least" max value, meaning that the implementation has to 
let you release your freshly created `sem` _at_ _least_ 8 times, but can 
also permit you to release, say, a 1000 or more times.

-- 
Best regards,
Andrey

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

#120032

On Wed, 11 Sep 2024 20:56:12 -0700
Andrey Tarasevich <andreytarasevich@hotmail.com> boringly babbled:
>On 09/11/24 8:03 AM, Muttley@dastardlyhq.com wrote:
>> then the semaphore can only be aquired TWO times, not 10. 
>
>Are you trying to troll people or what?

I get REALLY sick of people who think someone who's asking a question that
they know the answer to as trolling.

>If you write
>
>    std::counting_semaphore<10> sem(2);
>
>then the semaphore can be acquired 2 times. But it can also be released 
>instead at least 8 times, after which it can be acquired 10 times.

Thank you. You've explained in 2 lines what no one else managed. 

>See the math? 2 + 8 = 10?

No need to be patronising though thats par for the course on this group.

>The 10 is the "least" max value, meaning that the implementation has to 
>let you release your freshly created `sem` _at_ _least_ 8 times, but can 
>also permit you to release, say, a 1000 or more times.

Sounds profoundly useless but at least now I know. Though I can't imagine
when I'd ever use it.

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

#120035

On 12/09/2024 09:43, Muttley@dastardlyhq.com wrote:
> On Wed, 11 Sep 2024 20:56:12 -0700
> Andrey Tarasevich <andreytarasevich@hotmail.com> boringly babbled:
>> On 09/11/24 8:03 AM, Muttley@dastardlyhq.com wrote:
>>> then the semaphore can only be aquired TWO times, not 10.
>>
>> Are you trying to troll people or what?
> 
> I get REALLY sick of people who think someone who's asking a question that
> they know the answer to as trolling.
> 

You already accused everyone else in the thread of not knowing what they 
are talking about.  Let's try to keep things light.

>> If you write
>>
>>     std::counting_semaphore<10> sem(2);
>>
>> then the semaphore can be acquired 2 times. But it can also be released
>> instead at least 8 times, after which it can be acquired 10 times.
> 
> Thank you. You've explained in 2 lines what no one else managed.
> 
>> See the math? 2 + 8 = 10?
> 
> No need to be patronising though thats par for the course on this group.
> 
>> The 10 is the "least" max value, meaning that the implementation has to
>> let you release your freshly created `sem` _at_ _least_ 8 times, but can
>> also permit you to release, say, a 1000 or more times.
> 
> Sounds profoundly useless but at least now I know. Though I can't imagine
> when I'd ever use it.
> 


If you write :

	std::counting_semaphore<10> sem(2);

Then you can take the semaphore twice before blocking.  You can then 
release it up to 10 times.  But releasing it /more/ than ten times might 
be UB.  I say it /might/ be UB, because the semaphore has a value you 
can read with sem.max() which gives the true maximum value, which might 
be bigger than the 10 that you asked for.

It is not immediately obvious why this template parameter exists.  The 
answer is the internal implementation of the semaphore, which requires a 
queue of blocked threads.  A binary semaphore has a maximum of 1, and 
may be implemented more efficiently than a counting semaphore with a 
higher maximum.  For a low maximum, the queue might be implemented as a 
std::array<> of the appropriate size.  For a higher maximum, perhaps the 
implementation uses a std::vector<>.  So you pick the template parameter 
here to be at least as big as you will ever need for the semaphore, but 
aim to be as small as you can.

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

#120039

On Thu, 12 Sep 2024 13:30:56 +0200
David Brown <david.brown@hesbynett.no> boringly babbled:
>On 12/09/2024 09:43, Muttley@dastardlyhq.com wrote:
>> On Wed, 11 Sep 2024 20:56:12 -0700
>> Andrey Tarasevich <andreytarasevich@hotmail.com> boringly babbled:
>>> On 09/11/24 8:03 AM, Muttley@dastardlyhq.com wrote:
>>>> then the semaphore can only be aquired TWO times, not 10.
>>>
>>> Are you trying to troll people or what?
>> 
>> I get REALLY sick of people who think someone who's asking a question that
>> they know the answer to as trolling.
>> 
>
>You already accused everyone else in the thread of not knowing what they 
>are talking about.  Let's try to keep things light.

Well lets just say some of them should never consider teaching as a career.

>It is not immediately obvious why this template parameter exists.  The 
>answer is the internal implementation of the semaphore, which requires a 
>queue of blocked threads.  A binary semaphore has a maximum of 1, and 
>may be implemented more efficiently than a counting semaphore with a 
>higher maximum.  For a low maximum, the queue might be implemented as a 
>std::array<> of the appropriate size.  For a higher maximum, perhaps the 
>implementation uses a std::vector<>.  So you pick the template parameter 
>here to be at least as big as you will ever need for the semaphore, but 
>aim to be as small as you can.

Makes sense.

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

#120036

Am 12.09.2024 um 09:43 schrieb Muttley@dastardlyhq.com:

> Thank you. You've explained in 2 lines what no one else managed.

I said it also:

 > 10 is the maximum count the semaphore is allowed to reach ...

But you didn't understand that.


> Sounds profoundly useless but at least now I know. Though I can't imagine
> when I'd ever use it.

I also don't know what this is good for.

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

#120037

On 09/12/24 12:43 AM, Muttley@dastardlyhq.com wrote:
> 
> Sounds profoundly useless but at least now I know. Though I can't imagine
> when I'd ever use it.
> 

2 and 255 in this example

   std::counting_semaphore<255> sem(2);

follow pretty much the same semantics and serve pretty much the same 
purpose as 2 and 255 in the following example

   std::uint_least8_t n = 2;

(Even though the latter does not mention 255 explicitly, I hope you'll 
figure out where it hides.)

Whether you will ever "use" it or not is a different question.

-- 
Best regards,
Andrey

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | comp.lang.c++

csiph-web