Re: Ada.Containers and concurrent modification exception.

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2018-09-22 03:09, rakusu_klein@fastmail.jp wrote:
> суббота, 22 сентября 2018 г., 2:27:59 UTC+3 пользователь Randy Brukardt написал:
>> 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 missed the point, perhaps because I choose obscure names for properties. Sorry.
> 
> State_Type is a modification's counter with a wrap-around sematic. It counts modifications of an internal container's structure and exists in all container's instances (call them Actual_Modifications) and in every iterator's instance (call them Known_Modifications). When an iterator is created for an existing container, its counter is initialized by value of that container, so their values are equal. When container is changed by any public method, its modification counter is incremented by one. If modification process by public method involves an iterator, the modification counter inside the iterator also incremented by one. Before any modification will doing, values of counters for container and iterator will be compared for equality, and if The_Container.Actual_Modifications /= The_Cursor.Known_Modifications then raise Concurent_Modification.

This schema (sequence numbers) would invalidate all cursors. Not a good 
idea at all, in presence of many cursors. If there is only one cursor 
then there is also no problem. So the case looks quite marginal to me.

If I wanted to cover it, provided I ever used cursors, I would rather 
have the task ID to identify the owner of the change. This would be sort 
of re-entrant mutex with the difference that it would raise exception 
instead of blocking the offender.

In short:

1. The whole idea of fine interlocking/detection of concurrent access at 
the granularity level of individual container elements is wrong. It will 
never work, IMO.

2. The idea of raising exceptions concurrently at run-time to indicate 
tasking design errors is even worse.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de