On Fri, 20 Sep 2024 15:18:22 +0200
Bonita Montero <[email protected]> boringly babbled:

Just a ring-buffer with functional access:

A ring buffer can be written about 10 lines of code give or take. You seem to revel in making simple things complicated. One day post us your version of Hello World so we can have a laugh.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 20 Sep 2024 16:18:07 +0200
Bonita Montero <[email protected]> boringly babbled:

Am 20.09.2024 um 16:10 schrieb [email protected]:

A ring buffer can be written about 10 lines of code ...

A deque is also much more complex than you think it is necessary.

A deque is not needed for a ring buffer. Using one demonstrates you don't actually know what a ring buffer is. Hint: its an array with 2 pointers/indexes.
Done.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 20 Sep 2024 17:12:20 +0200
Bonita Montero <[email protected]> boringly babbled:

Am 20.09.2024 um 17:08 schrieb [email protected]:

A deque is not needed for a ring buffer.

Both usually serve the same purpose. A deque has iterators and therefore

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.

Using one demonstrates you don't actually know what a ring buffer is.

You are overburdened with my code and you didn't read it.
I implemented a very convenient to use ring-buffer.

A ring buffer doesn't require 420 lines of code. 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 20 Sep 2024 18:03:14 +0200
Bonita Montero <[email protected]> boringly babbled:

Am 20.09.2024 um 17:57 schrieb [email protected]:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[email protected] wrote this copyrighted missive and expects royalties:

On Fri, 20 Sep 2024 18:03:14 +0200
Bonita Montero <[email protected]> boringly babbled:

Am 20.09.2024 um 17:57 schrieb [email protected]:

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.

Apropos of nothing:

https://mathworld.wolfram.com/Trivial.html

According to the Nobel Prize-winning physicist Richard Feynman (Feynman
1997), mathematicians designate any theorem as "trivial" once a proof has
been obtained--no matter how difficult the theorem was to prove in the
first place. There are therefore exactly two types of true mathematical
propositions: trivial ones, and those which have not yet been proven.

--
Have at you!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 21 Sep 2024 14:25:18 +0200
Bonita Montero <[email protected]> boringly babbled:

Am 21.09.2024 um 14:18 schrieb Chris Ahlstrom:

I wrote a ringbuffer template class that is "similar" in size and scope.
Probably could refine it further.

He thinks he could write that in 10 lines without noticing the requirements.

I implented the sound output buffer for a virtual synth as a ring buffer.
As you can imagine time constraints were on the order of milliseconds as the buffer itself only contained 1/20th of a second of PCM data.

Normally the read and write pointers kept more or less in lock step depending on how the threads were running but not always, and you absolutely cannot have the sound stop so if the read pointer had to go around again so be it, you might hear a small click but usually not.

It didn't require 420 lines to implement because if it had it would have been so slow the sound would have been glitching all over the place.

Unlike you sitting in your ivory academic tower I have real world experience
of these things.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/21/24 08:18, Chris Ahlstrom wrote:

[email protected] wrote this copyrighted missive and expects royalties:

On Fri, 20 Sep 2024 18:03:14 +0200
Bonita Montero <[email protected]> boringly babbled:

Am 20.09.2024 um 17:57 schrieb [email protected]:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/21/24 16:59, Chris M. Thomasson wrote:

On 9/21/2024 10:03 AM, jseigh wrote:

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.

Nice! Well, supporting all of those modes all in one is interesting to
me Joe. Usually, to gain performance on the various queue types mpmc,
spsc, ect... They each have their own special algorithms. An algorithm
for a spsc is going to be different that a mpmc? Of course mpmc handles
all of those conditions, however, the per impl aspect is important?

The sp and sc code paths use simple stores rather than cas so there is
some speed up from that. Also there is a speed up from not ping ponging
cache so much. You see that speed up in mpmc with single producer
and/or consumer for the same reason though not as much.

Joe Seigh

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 21 Sep 2024 18:12:21 +0200
Bonita Montero <[email protected]> boringly babbled:

Am 21.09.2024 um 17:59 schrieb [email protected]:

I implented the sound output buffer for a virtual synth as a ring buffer.

That's a ring for _trivial_ C++ types, that's much easier. I can handle

Watch those goalposts move.

complex C++ types with a vector<>-like emplace( )and I move them when
the ring is resized; that's much more effort.

For complex types any sane person would just use an STL container as the
basis of a ring buffer instead of reinventing the wheel like you've done. And probably made it square in the process.

And you need a dozen postings to understand what the static and variable >initialization parameters for a semaphore are good for.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 22 Sep 2024 10:48:07 +0200
Bonita Montero <[email protected]> boringly babbled:

Am 22.09.2024 um 09:58 schrieb [email protected]:

For complex types any sane person would just use an STL container as the
basis of a ring buffer instead of reinventing the wheel like you've done.

And the STL-container is a magnitude more complex. I developed

So what? The containers are already written for you and many clever eyes and minds have made sure they're as efficient as possible.

this little alternative because I needed a qeue for MSVC which
is as efficient as libstdc++'s or libc++'s deque.

So why didn't you just use std::deque then with a couple of wrapper functions.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[email protected] 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 22 Sep 2024 11:49:45 +0200
Bonita Montero <[email protected]> boringly babbled:

Am 22.09.2024 um 11:01 schrieb [email protected]:

So what? The containers are already written for you and many clever eyes and >> minds have made sure they're as efficient as possible.

You're not just trying to explain away complexity with me because
it's too much for you.

If you say so poppet.

So why didn't you just use std::deque then with a couple of wrapper >functions.

Because MSVC's std::deque and Boost's boost::container::deque is
multiple times slower. I needed a fast solution for all platforms.

Then use a vector.

No doubt you'd write own crypto libraries too given half a chance.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 22 Sep 2024 06:49:13 -0400
Chris Ahlstrom <[email protected]> boringly babbled: >[email protected] 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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 22 Sep 2024 13:00:38 +0200
Bonita Montero <[email protected]> boringly babbled:

Am 22.09.2024 um 12:49 schrieb Chris Ahlstrom:

[email protected] 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 22 Sep 2024 17:31:34 +0200
Bonita Montero <[email protected]> boringly babbled:

Am 22.09.2024 um 17:16 schrieb [email protected]:

On Sun, 22 Sep 2024 06:49:13 -0400
Chris Ahlstrom <[email protected]> boringly babbled:

[email protected] 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 23 Sep 2024 09:36:32 +0200
Bonita Montero <[email protected]> boringly babbled:

Am 23.09.2024 um 09:35 schrieb [email protected]:

On Sun, 22 Sep 2024 17:31:34 +0200
Bonita Montero <[email protected]> boringly babbled:

Am 22.09.2024 um 17:16 schrieb [email protected]:

On Sun, 22 Sep 2024 06:49:13 -0400
Chris Ahlstrom <[email protected]> boringly babbled:

[email protected] 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 23 Sep 2024 09:31:09 -0000 (UTC)
[email protected] wrote:

On Mon, 23 Sep 2024 09:36:32 +0200
Bonita Montero <[email protected]> boringly babbled:

Am 23.09.2024 um 09:35 schrieb [email protected]:

On Sun, 22 Sep 2024 17:31:34 +0200
Bonita Montero <[email protected]> boringly babbled:

Am 22.09.2024 um 17:16 schrieb [email protected]:

On Sun, 22 Sep 2024 06:49:13 -0400
Chris Ahlstrom <[email protected]> boringly babbled:

[email protected] 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 23/09/2024 12:42, Michael S wrote:

On Mon, 23 Sep 2024 09:31:09 -0000 (UTC)
[email protected] wrote:

On Mon, 23 Sep 2024 09:36:32 +0200
Bonita Montero <[email protected]> boringly babbled:

Am 23.09.2024 um 09:35 schrieb [email protected]:

On Sun, 22 Sep 2024 17:31:34 +0200
Bonita Montero <[email protected]> boringly babbled:

Am 22.09.2024 um 17:16 schrieb [email protected]:

On Sun, 22 Sep 2024 06:49:13 -0400
Chris Ahlstrom <[email protected]> boringly babbled:

[email protected] 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)