Date: Fri, 04 Aug 2023 13:07:47 -0400
> there are no iterators.
I don't think a lock free container can support a general purpose iteration scheme. That would require a locking mechanism on the hole queue, which basically defeats its purpose.
Basically, atomicity of operations are provided only for the queue's ends, but the elements in between are not themselves atomic types (this couldn't work neither, because atomic types are not Copyable nor Moveable). Lock free algorithms normally operate with a constant set of atomic objects (only one for an spsc queue, if I remember correctly) that orders memory transactions of other memory locations. For lock free queues, the atomic access is provided for both ends.
If iterators were provided, then accessing the elements in between would incur a race condition.
In short, I don't think it is theoretically possible.
Julien V.
On August 3, 2023 7:05:49 p.m. EDT, Phil Bouchard via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>
>On 8/3/23 18:36, Phil Bouchard via Std-Proposals wrote:
>>
>> Wow... Boost wins hands down!
>> https://max0x7ba.github.io/atomic_queue/html/benchmarks.html
>
>Oh but its API is very limited... there are no iterators.
>
>
>
>--
>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.
>
>--
>Std-Proposals mailing list
>Std-Proposals_at_[hidden]
>https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
I don't think a lock free container can support a general purpose iteration scheme. That would require a locking mechanism on the hole queue, which basically defeats its purpose.
Basically, atomicity of operations are provided only for the queue's ends, but the elements in between are not themselves atomic types (this couldn't work neither, because atomic types are not Copyable nor Moveable). Lock free algorithms normally operate with a constant set of atomic objects (only one for an spsc queue, if I remember correctly) that orders memory transactions of other memory locations. For lock free queues, the atomic access is provided for both ends.
If iterators were provided, then accessing the elements in between would incur a race condition.
In short, I don't think it is theoretically possible.
Julien V.
On August 3, 2023 7:05:49 p.m. EDT, Phil Bouchard via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>
>On 8/3/23 18:36, Phil Bouchard via Std-Proposals wrote:
>>
>> Wow... Boost wins hands down!
>> https://max0x7ba.github.io/atomic_queue/html/benchmarks.html
>
>Oh but its API is very limited... there are no iterators.
>
>
>
>--
>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.
>
>--
>Std-Proposals mailing list
>Std-Proposals_at_[hidden]
>https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2023-08-04 17:07:59