Barrier re-evaluation issue with GNAT 4.3.2
in [ADA]
|
Prev: Newbie question: How to use gnat make
Next: Performance of access type : a tiny mistake in the WikiBook ?
From: John B. Matthews on 28 Sep 2009 08:39 In article <h9q34o$odd$1(a)news.eternal-september.org>, Reto Buerki <reet(a)codelabs.ch> wrote: > John B. Matthews wrote: > > I get the same result with FSF GNAT 4.3.4. I revised your code to follow > > the "protected Event" example seen here: > > > > <http://www.adaic.com/standards/95rat/RAThtml/rat95-p1-2.html#9> > > > > It seems to work. The compiler warns, "potentially blocking operation in > > protected operation" in Wakeup, although the Signal barrier is always > > true. I'm not sure the extra entries _should_ be required, but I think > > it might be more reliable in the face of multiple threads calling Wait. > > I don't know a reason why it wouldn't work under 4.3.2. > > Thanks for your effort in confirming the issue with GNAT 4.3.4 and for > the "protected Event" example. You're welcome. > We will see how we can integrate your idea into our project as a > workaround for the re-evaluation problem. This alternative approach also works, without using requeue: <http://www.adaic.com/standards/95rat/RAThtml/rat95-p2-9.html#2> I am troubled by the "potentially blocking operation" warning. Two things make me think it may be irrelevant: 1) Signal does not actually block, except to dequeue waiters, and 2) Wakeup, which enters Signal, is itself a protected procedure: <http://www.adaic.com/standards/05rm/html/RM-D-15.html> I'd welcome critical thoughts. -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Reto Buerki on 28 Sep 2009 09:25 John B. Matthews wrote: > In article <h9q34o$odd$1(a)news.eternal-september.org>, > Reto Buerki <reet(a)codelabs.ch> wrote: > >> John B. Matthews wrote: >>> I get the same result with FSF GNAT 4.3.4. I revised your code to follow >>> the "protected Event" example seen here: >>> >>> <http://www.adaic.com/standards/95rat/RAThtml/rat95-p1-2.html#9> >>> >>> It seems to work. The compiler warns, "potentially blocking operation in >>> protected operation" in Wakeup, although the Signal barrier is always >>> true. I'm not sure the extra entries _should_ be required, but I think >>> it might be more reliable in the face of multiple threads calling Wait. >>> I don't know a reason why it wouldn't work under 4.3.2. >> Thanks for your effort in confirming the issue with GNAT 4.3.4 and for >> the "protected Event" example. > > You're welcome. > >> We will see how we can integrate your idea into our project as a >> workaround for the re-evaluation problem. > > This alternative approach also works, without using requeue: Adapting your first example worked for us! We basically just moved the Alarm_Fired assignment from Wakeup() into an extra Signal() entry: procedure Wakeup (Event : in out Timing_Events.Timing_Event) is begin Signal; end Wakeup; entry Signal when True is begin Alarm_Fired := True; end Signal; This seems to cause a re-evaluation of the protected object barriers. It does not work if Signal() is a protected procedure, it must be an entry. > I am troubled by the "potentially blocking operation" warning. Two > things make me think it may be irrelevant: 1) Signal does not actually > block, except to dequeue waiters, and 2) Wakeup, which enters Signal, is > itself a protected procedure: > > <http://www.adaic.com/standards/05rm/html/RM-D-15.html> > > I'd welcome critical thoughts. We are not getting such a warning with our code, but we are not using "requeue" since our scenario is different.
From: Reto Buerki on 28 Sep 2009 10:05 Reto Buerki wrote: > John B. Matthews wrote: >> I am troubled by the "potentially blocking operation" warning. Two >> things make me think it may be irrelevant: 1) Signal does not actually >> block, except to dequeue waiters, and 2) Wakeup, which enters Signal, is >> itself a protected procedure: >> >> <http://www.adaic.com/standards/05rm/html/RM-D-15.html> >> >> I'd welcome critical thoughts. > > We are not getting such a warning with our code, but we are not using > "requeue" since our scenario is different. Update: we just noticed that the warning actually *does* show up but we missed it in the previous build. I also think the warning is irrelevant. It seems that the compiler is not smart enough to figure out that the Signal() entry is always open.
From: Jeffrey R. Carter on 28 Sep 2009 14:38 Reto Buerki wrote: > > Update: we just noticed that the warning actually *does* show up but we > missed it in the previous build. > > I also think the warning is irrelevant. It seems that the compiler is > not smart enough to figure out that the Signal() entry is always open. An entry call is always potentially blocking, regardless of its barrier; see ARM 9.5.1. Technically, this code contains a bounded error. Since the potentially blocking operation was detected, your program should raise Program_Error; GNAT pretends that it hasn't detected that the operation is potentially blocking and lets you get away with only a warning. Other compilers (and even other versions of GNAT) may actually raise Program_Error. -- Jeff Carter "Strange women lying in ponds distributing swords is no basis for a system of government." Monty Python & the Holy Grail 66
From: Dmitry A. Kazakov on 28 Sep 2009 14:51
On Mon, 28 Sep 2009 11:38:18 -0700, Jeffrey R. Carter wrote: > An entry call is always potentially blocking, regardless of its barrier; see ARM > 9.5.1. Technically, this code contains a bounded error. Since the potentially > blocking operation was detected, your program should raise Program_Error; GNAT > pretends that it hasn't detected that the operation is potentially blocking and > lets you get away with only a warning. Other compilers (and even other versions > of GNAT) may actually raise Program_Error. A small addition to above. If you wanted to call to an entry from inside a protected procedure you have two options: 1. the callee is made a protected procedure (can be factored out); 2. the caller is made an entry, and the call replaced with requeue. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |