I'm not following on how whether it is atomic helps in this case. Can you
go more into detail there?
The issue I ran into (and I think the OP ran into) is that
1. Task A gets a cursor and saves it,
2. does some process (either Ping or Close)
3. Iterates the cursor and saves the new one.
4. Repeats this in a loop until all cursors are checked
but sometimes Task B deletes the element of that saved cursor while Task A
is at step 2. Then when task A hits Step 3, the cursor is invalid and it
throws an exception. Prior to the bandaid I suggested, if that happened
during the "close" loop, it would completely deadlock the close process.
The symptom for my application was that when I hit the "terminate program"
button, it wouldn't terminate and future attempts to do so would not even
try again. The OP was seeing some different results, but I suspect it has
to do with the cursors as well.
My understanding of Atomic in Ada is that it guarantees that writes/reads
are not interrupted and that they happen in the order specified. In this
case, the problem isn't that the writes or reads are interrupted but that
the map itself is being modified while another task holds a cursor to it
(thus making the cursor invalid). If this happens during the Ping loop,
then it simply aborts the pinging process (maybe/maybe not detrimental).
If it interrupts the Close loop, then it (now) restarts the loop and tries
again (before it deadlocked).
I think we were trying to figure out if there was a better way to do this.
I agree with the Ping suggestion of deferring the deletions until after.
My 30 min attempt at making it better was to make the delete procedure an
entry, add a mutex like set of entries/procedures to the
connection_manager, seize the mutex before calling
Connection_Manager.First, and release the Mutex after the loop was done
(with the delete procedure now an entry, it would have to wait until after
the mutex was released). That would work for the close loop, but the
deletions in the Ping function made it too complex to figure out in a short
time. Plus I wasn't 100% certain it was a good idea or not to go that
route anyways.
Sorry for the long post!
On Tue, Jul 31, 2018 at 1:24 PM, Jeffrey R. Carter <jrcar...@acm.org> wrote:
> On 07/30/2018 06:03 AM, Jeremiah Breeden wrote:
> > In Gnoga.Server.Connection.adb search for the two usages of
> > Connection_Manager.First. Both will be in a loop. Essentially, one of
> the
> > problems is that the First operation saves a cursor form the Map, and the
> > Connection_Manager.Next tries to iterate on it. However, other tasks can
> > sometimes delete the element from the Map between those calls. David
> recently
> > added a bandaid that I came up with (an Exception Handler around the
> "Close" one
> > to reset the loop if it happens). The Ping one is already in an
> exception
> > handler, but the Ping function also calls Delete on the Map, so it can,
> in rare
> > cases, cause some weird crashes. It's a bit of a hairy implementation
> and
> > probably needs a revamp.
>
> Usually these things should be atomic, and I don't see a problem with both
> of
> these being in Connection_Manager.
>
> Ping may delete using the ID that is then passed to Next. I'm not sure
> what that
> will do, but it's usually a bad idea. Better is to collect a set of IDs to
> delete and delete them after the iteration.
>
> I haven't tried any of this yet.
>
> --
> Jeff Carter
> "My brain hurts!"
> Monty Python's Flying Circus
> 21
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Gnoga-list mailing list
> Gnoga-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gnoga-list
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list
