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

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

My deque-replaement

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

Contents

  My deque-replaement Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-20 15:18 +0200
    Re: My deque-replaement Muttley@dastardlyhq.com - 2024-09-20 14:10 +0000
      Re: My deque-replaement Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-20 16:18 +0200
        Re: My deque-replaement Muttley@dastardlyhq.com - 2024-09-20 15:08 +0000
          Re: My deque-replaement Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-20 17:12 +0200
            Re: My deque-replaement Muttley@dastardlyhq.com - 2024-09-20 15:57 +0000
              Re: My deque-replaement Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-20 18:03 +0200
                Re: My deque-replaement Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-20 18:09 +0200
                Re: My deque-replaement Muttley@dastardlyhq.com - 2024-09-21 09:40 +0000
                  Re: My deque-replaement Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-21 12:54 +0200
                  Re: My deque-replaement Chris Ahlstrom <OFeem1987@teleworm.us> - 2024-09-21 08:18 -0400
                    Re: My deque-replaement Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-21 14:25 +0200
                      Re: My deque-replaement Muttley@dastardlyhq.com - 2024-09-21 15:59 +0000
                        Re: My deque-replaement Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-21 18:12 +0200
                          Re: My deque-replaement Muttley@dastardlyhq.com - 2024-09-22 07:58 +0000
                            Re: My deque-replaement Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-22 10:48 +0200
                              Re: My deque-replaement Muttley@dastardlyhq.com - 2024-09-22 09:01 +0000
                                Re: My deque-replaement Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-22 11:49 +0200
                                  Re: My deque-replaement Muttley@dastardlyhq.com - 2024-09-22 15:13 +0000
                                    Re: My deque-replaement Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-22 17:28 +0200
                            Re: My deque-replaement Chris Ahlstrom <OFeem1987@teleworm.us> - 2024-09-22 06:49 -0400
                              Re: My deque-replaement Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-22 13:00 +0200
                                Re: My deque-replaement Muttley@dastardlyhq.com - 2024-09-22 15:19 +0000
                                  Re: My deque-replaement Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-22 17:30 +0200
                              Re: My deque-replaement Muttley@dastardlyhq.com - 2024-09-22 15:16 +0000
                                Re: My deque-replaement Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-22 17:31 +0200
                                  Re: My deque-replaement Muttley@dastardlyhq.com - 2024-09-23 07:35 +0000
                                    Re: My deque-replaement Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-23 09:36 +0200
                                      Re: My deque-replaement Muttley@dastardlyhq.com - 2024-09-23 09:31 +0000
                                        Re: My deque-replaement Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-23 11:47 +0200
                                        Re: My deque-replaement Michael S <already5chosen@yahoo.com> - 2024-09-23 13:42 +0300
                                          Re: My deque-replaement David Brown <david.brown@hesbynett.no> - 2024-09-23 14:09 +0200
                                            Re: My deque-replaement Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-23 19:00 +0200
                    Re: My deque-replaement jseigh <jseigh_es00@xemaps.com> - 2024-09-21 13:03 -0400
                      Re: My deque-replaement Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-21 19:13 +0200
                        Re: My deque-replaement jseigh <jseigh_es00@xemaps.com> - 2024-09-21 15:29 -0400
                          Re: My deque-replaement Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-22 08:23 +0200
                            Re: My deque-replaement jseigh <jseigh_es00@xemaps.com> - 2024-09-22 08:10 -0400
                              Re: My deque-replaement Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-22 15:03 +0200
                                Re: My deque-replaement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-22 11:37 -0700
                      Re: My deque-replaement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-21 13:59 -0700
                        Re: My deque-replaement jseigh <jseigh_es00@xemaps.com> - 2024-09-21 18:31 -0400
    Re: My deque-replaement wij <wyniijj5@gmail.com> - 2024-09-22 07:58 +0800
      Re: My deque-replaement Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-22 09:51 +0200
        Re: My deque-replaement wij <wyniijj5@gmail.com> - 2024-09-23 09:04 +0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#120173

Muttley@dastardlyhq.com wrote this copyrighted missive and expects royalties:

> <snip>
>
> And you required a number of posts using loads of gibberish to attempt to 
> explain yet you still failed. Meanwhile someone else managed it in 2 lines.

Ahhh, the famous "2 lines of code" claim.

-- 
When one burns one's bridges, what a very nice fire it makes.
		-- Dylan Thomas

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

#120174

Am 22.09.2024 um 12:49 schrieb Chris Ahlstrom:
> Muttley@dastardlyhq.com wrote this copyrighted missive and expects royalties:
> 
>> <snip>
>>
>> And you required a number of posts using loads of gibberish to attempt to
>> explain yet you still failed. Meanwhile someone else managed it in 2 lines.
> 
> Ahhh, the famous "2 lines of code" claim.
> 

Muttley denies every language feature he doesn't understand in 10s.

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

#120183

On Sun, 22 Sep 2024 13:00:38 +0200
Bonita Montero <Bonita.Montero@gmail.com> boringly babbled:
>Am 22.09.2024 um 12:49 schrieb Chris Ahlstrom:
>> Muttley@dastardlyhq.com wrote this copyrighted missive and expects royalties:
>
>> 
>>> <snip>
>>>
>>> And you required a number of posts using loads of gibberish to attempt to
>>> explain yet you still failed. Meanwhile someone else managed it in 2 lines.
>> 
>> Ahhh, the famous "2 lines of code" claim.
>> 
>
>Muttley denies every language feature he doesn't understand in 10s.

Wtf is "in 10s" supposed to mean?

As for not understanding - its a case of law of diminishing returns. No one
can learn the whole of C++ anymore unlike C which means any one bit of code
might present challenges to even an experienced dev at maintenance time 
which often means poorer quality software.

Unfortuntely C++ is now a dogs dinner. I use it because I know it but I
certainly wouldn't choose it if I didn't.

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

#120186

Am 22.09.2024 um 17:19 schrieb Muttley@dastardlyhq.com:

> As for not understanding - its a case of law of diminishing returns. No one
> can learn the whole of C++ anymore unlike C which means any one bit of code
> might present challenges to even an experienced dev at maintenance time
> which often means poorer quality software.

I can handle 90% of the language and I would have no problems learning
the remaining 10% if necessary. I'm constantly updating my knowledge
by buying books on Leanpu which update me for newer standards.

> Unfortuntely C++ is now a dogs dinner. I use it because I know it but I
> certainly wouldn't choose it if I didn't.

You have the choice of writing all details yourself like in C or to use
a more powerful language. Then you'd need to learn advanced technologies
once and after some time you save a lot of time and work.

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

#120182

On Sun, 22 Sep 2024 06:49:13 -0400
Chris Ahlstrom <OFeem1987@teleworm.us> boringly babbled:
>Muttley@dastardlyhq.com wrote this copyrighted missive and expects royalties:
>
>> <snip>
>>
>> And you required a number of posts using loads of gibberish to attempt to 
>> explain yet you still failed. Meanwhile someone else managed it in 2 lines.
>
>Ahhh, the famous "2 lines of code" claim.

Who said anything about code? 

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

#120187

Am 22.09.2024 um 17:16 schrieb Muttley@dastardlyhq.com:
> On Sun, 22 Sep 2024 06:49:13 -0400
> Chris Ahlstrom <OFeem1987@teleworm.us> boringly babbled:
>> Muttley@dastardlyhq.com wrote this copyrighted missive and expects royalties:
>>
>>> <snip>
>>>
>>> And you required a number of posts using loads of gibberish to attempt to
>>> explain yet you still failed. Meanwhile someone else managed it in 2 lines.
>>
>> Ahhh, the famous "2 lines of code" claim.
> 
> Who said anything about code?
> 

You said you could replace my code with 10 lines of code - without
noticing what it does.

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

#120199

On Sun, 22 Sep 2024 17:31:34 +0200
Bonita Montero <Bonita.Montero@gmail.com> boringly babbled:
>Am 22.09.2024 um 17:16 schrieb Muttley@dastardlyhq.com:
>> On Sun, 22 Sep 2024 06:49:13 -0400
>> Chris Ahlstrom <OFeem1987@teleworm.us> boringly babbled:
>>> Muttley@dastardlyhq.com wrote this copyrighted missive and expects
>royalties:
>>>
>>>> <snip>
>>>>
>>>> And you required a number of posts using loads of gibberish to attempt to
>>>> explain yet you still failed. Meanwhile someone else managed it in 2 lines.
>
>>>
>>> Ahhh, the famous "2 lines of code" claim.
>> 
>> Who said anything about code?
>> 
>
>You said you could replace my code with 10 lines of code - without
>noticing what it does.

I was refering to how someone explained the reason for the template param of 
semaphores in 2 lines whereas you and others spent paragraphs trying and
failing. 

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

#120200

Am 23.09.2024 um 09:35 schrieb Muttley@dastardlyhq.com:
> On Sun, 22 Sep 2024 17:31:34 +0200
> Bonita Montero <Bonita.Montero@gmail.com> boringly babbled:
>> Am 22.09.2024 um 17:16 schrieb Muttley@dastardlyhq.com:
>>> On Sun, 22 Sep 2024 06:49:13 -0400
>>> Chris Ahlstrom <OFeem1987@teleworm.us> boringly babbled:
>>>> Muttley@dastardlyhq.com wrote this copyrighted missive and expects
>> royalties:
>>>>
>>>>> <snip>
>>>>>
>>>>> And you required a number of posts using loads of gibberish to attempt to
>>>>> explain yet you still failed. Meanwhile someone else managed it in 2 lines.
>>
>>>>
>>>> Ahhh, the famous "2 lines of code" claim.
>>>
>>> Who said anything about code?
>>>
>>
>> You said you could replace my code with 10 lines of code - without
>> noticing what it does.
> 
> I was refering to how someone explained the reason for the template param of
> semaphores in 2 lines whereas you and others spent paragraphs trying and
> failing.

You needed several descriptions which were all correct.

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

#120205

On Mon, 23 Sep 2024 09:36:32 +0200
Bonita Montero <Bonita.Montero@gmail.com> boringly babbled:
>Am 23.09.2024 um 09:35 schrieb Muttley@dastardlyhq.com:
>> On Sun, 22 Sep 2024 17:31:34 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> boringly babbled:
>>> Am 22.09.2024 um 17:16 schrieb Muttley@dastardlyhq.com:
>>>> On Sun, 22 Sep 2024 06:49:13 -0400
>>>> Chris Ahlstrom <OFeem1987@teleworm.us> boringly babbled:
>>>>> Muttley@dastardlyhq.com wrote this copyrighted missive and expects
>>> royalties:
>>>>>
>>>>>> <snip>
>>>>>>
>>>>>> And you required a number of posts using loads of gibberish to attempt to
>
>>>>>> explain yet you still failed. Meanwhile someone else managed it in 2
>lines.
>>>
>>>>>
>>>>> Ahhh, the famous "2 lines of code" claim.
>>>>
>>>> Who said anything about code?
>>>>
>>>
>>> You said you could replace my code with 10 lines of code - without
>>> noticing what it does.
>> 
>> I was refering to how someone explained the reason for the template param of
>> semaphores in 2 lines whereas you and others spent paragraphs trying and
>> failing.
>
>You needed several descriptions which were all correct.

Several descriptions which all parotted the cppreference page which doesn't
explain it properly otherwise I wouldn't have asked.

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

#120210

Am 23.09.2024 um 11:31 schrieb Muttley@dastardlyhq.com:

> Several descriptions which all parotted the cppreference page which doesn't
> explain it properly otherwise I wouldn't have asked.

https://en.cppreference.com/w/cpp/thread/counting_semaphore
... is correct.

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

#120211

On Mon, 23 Sep 2024 09:31:09 -0000 (UTC)
Muttley@dastardlyhq.com wrote:

> On Mon, 23 Sep 2024 09:36:32 +0200
> Bonita Montero <Bonita.Montero@gmail.com> boringly babbled:
> >Am 23.09.2024 um 09:35 schrieb Muttley@dastardlyhq.com:  
> >> On Sun, 22 Sep 2024 17:31:34 +0200
> >> Bonita Montero <Bonita.Montero@gmail.com> boringly babbled:  
> >>> Am 22.09.2024 um 17:16 schrieb Muttley@dastardlyhq.com:  
> >>>> On Sun, 22 Sep 2024 06:49:13 -0400
> >>>> Chris Ahlstrom <OFeem1987@teleworm.us> boringly babbled:  
> >>>>> Muttley@dastardlyhq.com wrote this copyrighted missive and
> >>>>> expects  
> >>> royalties:  
> >>>>>  
> >>>>>> <snip>
> >>>>>>
> >>>>>> And you required a number of posts using loads of gibberish to
> >>>>>> attempt to  
> >  
> >>>>>> explain yet you still failed. Meanwhile someone else managed
> >>>>>> it in 2  
> >lines.  
> >>>  
> >>>>>
> >>>>> Ahhh, the famous "2 lines of code" claim.  
> >>>>
> >>>> Who said anything about code?
> >>>>  
> >>>
> >>> You said you could replace my code with 10 lines of code - without
> >>> noticing what it does.  
> >> 
> >> I was refering to how someone explained the reason for the
> >> template param of semaphores in 2 lines whereas you and others
> >> spent paragraphs trying and failing.  
> >
> >You needed several descriptions which were all correct.  
> 
> Several descriptions which all parotted the cppreference page which
> doesn't explain it properly otherwise I wouldn't have asked.
>

I wonder which of explanations that you had gotten do you consider
satisfactory?

If you are thinking about explanation given by David Brown then I am
quite sure that despite sounding convincing his explanation is wrong.
In a typical implementation counting semaphores *do not* maintain list
of IDs of waiting threads within std::counting_semaphore object.

The article on cppreference.com that does not try to explain why
LeastMaxValue is a template parameter seems to me as the most adequate,
because logical explanation for that choice does not exist.
It would have been much more logical if the type of the counter rather
than its max value had been chosen as a template parameter. Of course
with requirement that the type has to be signed integer.

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

#120212

On 23/09/2024 12:42, Michael S wrote:
> On Mon, 23 Sep 2024 09:31:09 -0000 (UTC)
> Muttley@dastardlyhq.com wrote:
> 
>> On Mon, 23 Sep 2024 09:36:32 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> boringly babbled:
>>> Am 23.09.2024 um 09:35 schrieb Muttley@dastardlyhq.com:
>>>> On Sun, 22 Sep 2024 17:31:34 +0200
>>>> Bonita Montero <Bonita.Montero@gmail.com> boringly babbled:
>>>>> Am 22.09.2024 um 17:16 schrieb Muttley@dastardlyhq.com:
>>>>>> On Sun, 22 Sep 2024 06:49:13 -0400
>>>>>> Chris Ahlstrom <OFeem1987@teleworm.us> boringly babbled:
>>>>>>> Muttley@dastardlyhq.com wrote this copyrighted missive and
>>>>>>> expects
>>>>> royalties:
>>>>>>>   
>>>>>>>> <snip>
>>>>>>>>
>>>>>>>> And you required a number of posts using loads of gibberish to
>>>>>>>> attempt to
>>>   
>>>>>>>> explain yet you still failed. Meanwhile someone else managed
>>>>>>>> it in 2
>>> lines.
>>>>>   
>>>>>>>
>>>>>>> Ahhh, the famous "2 lines of code" claim.
>>>>>>
>>>>>> Who said anything about code?
>>>>>>   
>>>>>
>>>>> You said you could replace my code with 10 lines of code - without
>>>>> noticing what it does.
>>>>
>>>> I was refering to how someone explained the reason for the
>>>> template param of semaphores in 2 lines whereas you and others
>>>> spent paragraphs trying and failing.
>>>
>>> You needed several descriptions which were all correct.
>>
>> Several descriptions which all parotted the cppreference page which
>> doesn't explain it properly otherwise I wouldn't have asked.
>>
> 
> I wonder which of explanations that you had gotten do you consider
> satisfactory?
> 
> If you are thinking about explanation given by David Brown then I am
> quite sure that despite sounding convincing his explanation is wrong.
> In a typical implementation counting semaphores *do not* maintain list
> of IDs of waiting threads within std::counting_semaphore object.

I am not at all sure how counting semaphores might be implemented on 
different OS's, and I did not claim that they actually held such lists. 
I was merely pointing out plausible reasons for why a template class 
like this might have an integer template parameter, and how it could be 
used for more efficient implementations depending on the maximum count. 
Perhaps a more realistic case would be an OS which provided a hybrid 
mutex / binary semaphore object and implements a counting semaphore on 
top of that - then a std::counting_semaphore<1> could be significantly 
more efficient than one with a maximum count greater than 1.

So please don't read more into my comments than I wrote.

> 
> The article on cppreference.com that does not try to explain why
> LeastMaxValue is a template parameter seems to me as the most adequate,
> because logical explanation for that choice does not exist.
> It would have been much more logical if the type of the counter rather
> than its max value had been chosen as a template parameter. Of course
> with requirement that the type has to be signed integer.
> 

Having a LeastMaxValue parameter fits better with usage and offers more 
flexibility to the implementation, and is therefore a better choice than 
specifying an underlying type for the counter.

The user of a counting semaphore is not interested in details of the 
type used for the counter - but they are, or should be, interested in a 
maximum value for the number of times the counter can be raised.  (It 
would be nice if the default value were specified to be the maximum 
efficiently supported.)

Semaphores are not wrappers around an integer type, so it does not make 
sense to define them that way.

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

#120229

Am 23.09.2024 um 14:09 schrieb David Brown:

> I am not at all sure how counting semaphores might be implemented on 
> different OS's, and I did not claim that they actually held such lists. 
> I was merely pointing out plausible reasons for why a template class 
> like this might have an integer template parameter, and how it could be 
> used for more efficient implementations depending on the maximum count. 
> Perhaps a more realistic case would be an OS which provided a hybrid 
> mutex / binary semaphore object and implements a counting semaphore on 
> top of that - then a std::counting_semaphore<1> could be significantly 
> more efficient than one with a maximum count greater than 1.

I think because C++20 requires futexe (notify() / wait() on atomics)
no implementer misses to use futexe for semaphores. In the following
code, g++, clang++ and MSVC initialize the semaphore with a single
move.

#include <optional>
#include <semaphore>

using namespace std;

optional<counting_semaphore<123>> optSem;

void fn()
{
	optSem.emplace( 0 );
}

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

#120151

On 9/21/24 08:18, Chris Ahlstrom wrote:
> Muttley@dastardlyhq.com wrote this copyrighted missive and expects royalties:
> 
>> On Fri, 20 Sep 2024 18:03:14 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> boringly babbled:
>>> Am 20.09.2024 um 17:57 schrieb Muttley@dastardlyhq.com:
>>>
>>>> No, they don't. A deque can have an unbounded (except by memory)
>>>> number of items whereas a ring buffer is by design a fixed size.
>>>
>>> A ring-buffer can be growing, my implementation also does grow.
>>
>> A ringbuffer that can grow is not a ring buffer, its a deque as you figured
>> out.
>>
>>> The Boost ringbuffer also can grow.
>>
>> Boost has a lot to answer for in many areas.
>>
>>>> People like yourself are responsible for the absurd amount of bloat
>>>> in modern code and ridiculously powerful CPUs being required just
>>>> to run office style applications and web pages.
>>>
>>> The "bloat" results in very few code of who uses this "bloat".
>>> You're simply overburdened. Have a look at the standard library
>>
>> Am I? I think it might be you who can't think clearly enough to write a
>> clean simple algorithm for a simple data structure.
>>
>>> code, it's much more complex for things which might look trivial
>>> to you.
>>
>> Ring buffers are trivial.
> 
> Depends what you want. The ringbuffer.c module in the jack2 project is 420
> lines including comments and #ifdefs. It also provides optional locking, and
> some convenience functions.
> 
> I wrote a ringbuffer template class that is "similar" in size and scope.
> Probably could refine it further.
> 

I have a ringbuffer implementation that is lock-free, internally ABA
proof, and is about 400 loc I think.  It supports mpmc, spsc, spmc,
and mpsc.

Joe Seigh

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

#120152

Am 21.09.2024 um 19:03 schrieb jseigh:

> I have a ringbuffer implementation that is lock-free, internally ABA
> proof, and is about 400 loc I think.  It supports mpmc, spsc, spmc,
> and mpsc.

Lock-free ring-buffers are technically nice but suck since they have
to be polled. Better a mutex'd solution with a mutex that has a limited
spin-count and a futex for the slow path.

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

#120153

On 9/21/24 13:13, Bonita Montero wrote:
> Am 21.09.2024 um 19:03 schrieb jseigh:
> 
>> I have a ringbuffer implementation that is lock-free, internally ABA
>> proof, and is about 400 loc I think.  It supports mpmc, spsc, spmc,
>> and mpsc.
> 
> Lock-free ring-buffers are technically nice but suck since they have
> to be polled. Better a mutex'd solution with a mutex that has a limited
> spin-count and a futex for the slow path.
> 

Lock-free is desirable for certain situations.  Also there is a certain
presumption that if you are using lock-free mutable data structures you
sort of know what you are doing.  Not rocket science level stuff.
Closer to "don't use uint8_t if the values might exceed 256" or "don't
do unbounded recursion" or "don't use evil regex's".

Joe Seigh

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

#120159

Am 21.09.2024 um 21:29 schrieb jseigh:

> Lock-free is desirable for certain situations.  Also there is a certain
> presumption that if you are using lock-free mutable data structures you
> sort of know what you are doing.  Not rocket science level stuff.
> Closer to "don't use uint8_t if the values might exceed 256" or "don't
> do unbounded recursion" or "don't use evil regex's".

Show ma en open source project that uses lock-free queues without a
slow path.

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

#120178

On 9/22/24 02:23, Bonita Montero wrote:
> Am 21.09.2024 um 21:29 schrieb jseigh:
> 
>> Lock-free is desirable for certain situations.  Also there is a certain
>> presumption that if you are using lock-free mutable data structures you
>> sort of know what you are doing.  Not rocket science level stuff.
>> Closer to "don't use uint8_t if the values might exceed 256" or "don't
>> do unbounded recursion" or "don't use evil regex's".
> 
> Show ma en open source project that uses lock-free queues without a
> slow path.
> 

Not sure what you mean there.  The advantage of a lock-free queue over
a lock based one is that if in the middle of an enqueue/dequeue
operation a thread preempts, all the other threads don't block
waiting for that thread to get dispatched again, complete the
enqueue/dequeue operation and release the lock.

As far as slow path, if you mean waiting for queue to be not empty or
not full, there are eventcounts which can be used to wait for those
conditions w/o busy polling and still keep everything lock-free.
Check out folly's eventcount for more information.

Joe Seigh

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

#120179

Am 22.09.2024 um 14:10 schrieb jseigh:

> Not sure what you mean there.  The advantage of a lock-free queue
> over a lock based one is that if in the middle of an enqueue/dequeue
> operation a thread preempts, all the other threads don't block
> waiting for that thread to get dispatched again, complete the
> enqueue/dequeue operation and release the lock.

But the producer could spin if the queue is full or the consumer
could spin if the queue is empty. This is usually inacceptable
because it's inefficient.

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

#120190

On 9/22/2024 6:03 AM, Bonita Montero wrote:
> Am 22.09.2024 um 14:10 schrieb jseigh:
> 
>> Not sure what you mean there.  The advantage of a lock-free queue
>> over a lock based one is that if in the middle of an enqueue/dequeue
>> operation a thread preempts, all the other threads don't block
>> waiting for that thread to get dispatched again, complete the
>> enqueue/dequeue operation and release the lock.
> 
> But the producer could spin if the queue is full or the consumer
> could spin if the queue is empty. This is usually inacceptable
> because it's inefficient.
> 

Are you familiar with eventcounts? The eventcount can be used to wait on 
those conditions, well, only if a thread wants to...

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web