Date: Fri, 23 Feb 2024 12:36:30 -0500
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_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> 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_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>
> 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_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> 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_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> 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_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-23 17:36:31