From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Ada.Containers and concurrent modification exception.
Date: Fri, 21 Sep 2018 18:27:57 -0500
Organization: JSA Research & Innovation
Message-ID: <po3upu$9je$1@franka.jacob-sparre.dk>
References: <c50e849d-d14c-425d-99f6-75dce5fc3927@googlegroups.com>
 <ly1s9pjxfr.fsf@pushface.org>
 <64f5bbad-2f06-4ea9-aa33-8c66e9cbb2a5@googlegroups.com>
Injection-Date: Fri, 21 Sep 2018 23:27:58 -0000 (UTC)
Injection-Info: franka.jacob-sparre.dk;
 posting-host="rrsoftware.com:24.196.82.226";
	logging-data="9838"; mail-complaints-to="news@jacob-sparre.dk"
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246
Xref: reader02.eternal-september.org comp.lang.ada:54399
Date: 2018-09-21T18:27:57-05:00
List-Id: <comp.lang.ada>


<rakusu_klein@fastmail.jp> wrote in message 
news:64f5bbad-2f06-4ea9-aa33-8c66e9cbb2a5@googlegroups.com...

>In operations with container I just compare States in Container and Cursor 
>and
>throw a Concurent_Modification exception if they are not equal. If any 
>operation
>deletes a Node, I just increment States in Container and Cursor, if it 
>used, - it
>makes invalid any other Cursors. It may be stupid, but works well for me.

And it would be wrong: deleting a node from the Map only invalidates cursors 
that point at that node, not cursors that point at other nodes in the Map. 
Those can continue to be used (for instance, if stored in another container) 
until their nodes or the map as a whole are deleted.

You would have to use such a counter in each *node* for this to work. An 
implementation on this line is the 99% percent solution that I was 
suggesting, but it could fail in various circumstances, most likely when a 
container is destroyed and a new one created in the same location (as could 
happen with a commonly called subprogram). It also could fail if the counter 
wrapped arround (as it could if many nodes are created and destroyed 
repeatedly).

                                               Randy.