Re: [PATCH v2] Change alarm cancel function to thread-safe:

["Ananyev, Konstantin" <konstantin.ananyev-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]

> > As I remember the purpose of the patch was to fix the race condition inside rte_alarm library.
> > I believe that the patch provided by Michal & Pawel fixes the issues you discovered.
> > If you think, that is not the case, could you please provide a list of remaining issues?
> > Excluding ones that you just don't like it, and you are not happy with rte_alarm API in total?


> Gladly.  As Pawel explained the race, its possible that, after calling
> rte_eal_alarm_cancel, an in-flight execution of an alarm callback may still be
> running.  The problem with that ostensibly is that data which is being accessed
> by the callback might be then accessed in parallel with another process leading
> to data corruption or some other problem. The issue I have with his patch is
> that it doesn't completely close the race.  While it does close the race for the
> condition in whcih thread B is running the alarm callback while thread A is
> executing the cancel operation, it does not close the case for when a single
> thread B is running the cancel operation, as the in-flight execution itself is
> still active.

A bit puzzled here:
Are you saying that calling alarm_cancel() for itself inside eal_alarm_callback() might cause a problem?
I still don't see how.

>  If such a cancellation occurs via an intermediary function (i.e.
> one which is not aware that it is explicitly running an alarm callback, which
> signals another thread to execute via some other method (ipc communication,
> etc), the same data corruption may occur, because the canceled and complete
> guarantee has been violated.
>