Date: Thu, 22 Feb 2024 10:16:55 -0500
On 2/22/24 08:44, Jens Maurer wrote:
>
>
> On 22/02/2024 06.49, Phil Bouchard via Std-Proposals wrote:
>> Greetings,
>>
>> I wrote the aforementioned for my employer a while ago and the containers were heavily tested on a multicore node.
>>
>> The headers are very generic, efficient and compact. For the sake of not reinventing the wheel I was considering purchasing my own code and making it Open Source.
>>
>> If I do so is that something the ISO committee would be interested to integrate into the standards?
>
> Concurrent data structures come in a lot of varieties, responding
> to different requirements (or absence thereof).
>
> For a very basic example, a 1:1 queue (single sender, single receiver)
> is very different from an n:m queue (potentially multiple senders and
> receivers).
>
> In general, the C++ committee wants to see a thorough investigation
> of the landscape before standardizing a particular approach.
> (We want to make sure the choice we make is the right one, to the
> best of our abilities.)
It's a new concept as well and way to write code. I think it's time for
C++ to harness and scale up its own concurrent power.
>
> So, how do your containers (which ones?) compare against other
> solutions out there? What problems do they solve? Which ones
> are out of scope? etc.
There's no single producer / single consumer limitations or anything
like that. It's basically a thread-safe cyclic container of shared_ptr
of elements, where temporary containers are created by threads to hold a
copy of the elements.
Ideally we could have atomic containers they are based on but alas this
is not the case so they are not lock-free but they are implemented very
efficiently.
It's already used by real-time AI algorithms and image processing with
16 concurrent cameras with no problem.
>
>
> On 22/02/2024 06.49, Phil Bouchard via Std-Proposals wrote:
>> Greetings,
>>
>> I wrote the aforementioned for my employer a while ago and the containers were heavily tested on a multicore node.
>>
>> The headers are very generic, efficient and compact. For the sake of not reinventing the wheel I was considering purchasing my own code and making it Open Source.
>>
>> If I do so is that something the ISO committee would be interested to integrate into the standards?
>
> Concurrent data structures come in a lot of varieties, responding
> to different requirements (or absence thereof).
>
> For a very basic example, a 1:1 queue (single sender, single receiver)
> is very different from an n:m queue (potentially multiple senders and
> receivers).
>
> In general, the C++ committee wants to see a thorough investigation
> of the landscape before standardizing a particular approach.
> (We want to make sure the choice we make is the right one, to the
> best of our abilities.)
It's a new concept as well and way to write code. I think it's time for
C++ to harness and scale up its own concurrent power.
>
> So, how do your containers (which ones?) compare against other
> solutions out there? What problems do they solve? Which ones
> are out of scope? etc.
There's no single producer / single consumer limitations or anything
like that. It's basically a thread-safe cyclic container of shared_ptr
of elements, where temporary containers are created by threads to hold a
copy of the elements.
Ideally we could have atomic containers they are based on but alas this
is not the case so they are not lock-free but they are implemented very
efficiently.
It's already used by real-time AI algorithms and image processing with
16 concurrent cameras with no problem.
-- Logo <https://www.fornux.com/> *Phil Bouchard* facebook icon <https://www.linkedin.com/in/phil-bouchard-5723a910/> Founder & CEO T: (819) 328-4743 E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com> 320-345 de la Gauchetière Ouest| Montréal (Qc), H2Z 0A2 Canada Banner <https://goglobalawards.org/> Le message ci-dessus, ainsi que les documents l'accompagnant, sont destinés uniquement aux personnes identifiées et peuvent contenir des informations privilégiées, confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce message par erreur, veuillez le détruire. This communication (and/or the attachments) is intended for named recipients only and may contain privileged or confidential information which is not to be disclosed. If you received this communication by mistake please destroy all copies.
Received on 2024-02-22 15:16:58