Date: Fri, 23 Feb 2024 18:06:17 +0000 (UTC)
Yes, Iterators are a challenge even in single thread, as modifying the content can invalidate them. I recently coded to save an iterator, it++, erase saved iterator so I could continue using that iterator, a pain. It's hard to imagine a thread safe default behavior. I flash on watching the Oracle RDBMS oversight view have old pages tied to old queries in process and new pages for updated data in the tables supporting new queries. I am not sure the world is ready for an iterator that works on a deep copy of the entire container, or containers with internal versions!
What is the "classic" cure for iterators opened on a container that is subsequently modified?
But my proposal would allow simple synchronization of any class with no new code.
If we wanted to go crazy, we could support exclusive write and multiple read lock behaviors, with pending write blocking subsequent read, maybe triggered by const. That is tricky with methods that only conditionally modify -- they would get an exclusive write lock regardless!
On Friday, February 23, 2024 at 12:29:13 PM EST, Breno Guimarães <brenorg_at_[hidden]> 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?
Em sex., 23 de fev. de 2024 14:21, David G. Pickett via Std-Proposals <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]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
What is the "classic" cure for iterators opened on a container that is subsequently modified?
But my proposal would allow simple synchronization of any class with no new code.
If we wanted to go crazy, we could support exclusive write and multiple read lock behaviors, with pending write blocking subsequent read, maybe triggered by const. That is tricky with methods that only conditionally modify -- they would get an exclusive write lock regardless!
On Friday, February 23, 2024 at 12:29:13 PM EST, Breno Guimarães <brenorg_at_[hidden]> 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?
Em sex., 23 de fev. de 2024 14:21, David G. Pickett via Std-Proposals <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]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2024-02-23 18:06:21