Ok, with that in mind, the current set of loops are not being done
atomically (it is not done inside a protected operation). So the next
question is how do we get to where they are done in a more atomic manner.
I started off with a mutex like implementation for the close loop.since the
close procedure could potentially block (and thus could not go in a
protected operation). That wouldn't work for the ping loop without
restructuring the ping procedure itself (and pull out the deletions to be
done afterwards as mentioned in an earlier email/post).
On Fri, Aug 3, 2018 at 5:18 AM, Jeffrey R. Carter <jrcar...@acm.org> wrote:
> On 08/03/2018 01:52 AM, Jeremiah Breeden wrote:
> > 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 meant atomic in its generic sense, not as aspect/pragma Atomic. If the
> loop is
> an atomic operation (provided by the PO), then the other task cannot
> interfere
> with it. During the Close loop, the program is ending (IIUC), so it doesn't
> matter how long it takes. For Ping, how long the loop takes might be an
> issue,
> but since it's only done once per minute, if there aren't too many
> connections,
> it might be acceptable.
>
> --
> Jeff Carter
> "I like it when the support group complains that they have
> insufficient data on mean time to repair bugs in Ada software."
> Robert I. Eachus
> 91
>
> ------------------------------------------------------------
> ------------------
> 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
