shared pointers perhaps help in the very simple find case.

 

But say (still a simple example without multiple containers and without circular references) you want to display the first and last entry of a container, if its size is > 1; and the only entry, if its size is 1.

Then you have to prevent any change on the container by other threads, between reading the size and reading the entries.

Otherwise it could happen that you display the same entry twice.
 

-----Ursprüngliche Nachricht-----
Von: Phil Bouchard via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Fr 23.02.2024 18:36
Betreff: Re: [std-proposals] High Performance Thread-Safe C++
An: std-proposals@lists.isocpp.org;
CC: Phil Bouchard <boost@fornux.com>; David G. Pickett <dgpickett@aol.com>;


On 2/23/24 12:28, Breno Guimarães via Std-Proposals wrote:
> It's hard to be transparent like that because thread safety isn't
> achieved simply by adding mutexes to all methods.
>
> For example, "find" can lock a mutex, search the container and unlock
> the mutex, but it will return an iterator to the container.
> What happens when that container is changed while the caller of "find"
> is using the resulting iterator?

That's why the container needs to be a container of shared_ptrs to node
this way the iterator will keep the node alive for the time being.

> Em sex., 23 de fev. de 2024 14:21, David G. Pickett via Std-Proposals
> <std-proposals@lists.isocpp.org <mailto:std-proposals@lists.isocpp.org>>
> escreveu:
>
>     It'd be nice if the language had a way to say that a particular
>     container *instance* needs to be thread safe, so all methods are
>     mutex protected.  The developer could add a reserved word in the
>     declaration.  This way, users are not accidentally using a mutex
>     unnecessarily.  The compiler can add the mutex lock to all methods
>     when invoked, somewhat like a MACRO but less global.  We don't want
>     to be like Java, and have to remember which container name is
>     synchronized, e.g ArrayList, Vector; StringBuffer, StringBuilder, or
>     hve duffers using a synchronized container when not needed.
>     --
>     Std-Proposals mailing list
>     Std-Proposals@lists.isocpp.org <mailto:Std-Proposals@lists.isocpp.org>
>     https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>     <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>

--
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@fornux.com| 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals