Barrier re-evaluation issue with GNAT 4.3.2

[Reto Buerki <reet@codelabs.ch>]

Hi,

The test code below implements a simple alarm clock which should wakeup
the task waiting on the "Wait_For_Wakeup" entry.

With GNAT 4.3.2 on Debian/stable this does not work. The main task
remains queued on the entry even though the Wakeup-handler is invoked
correctly by the Timing_Event.

Compiling the same code with GNAT 4.4.1-5 (on Debian/SID) or GNAT GPL
2009 leads to the expected behavior: The main task terminates after the
alarm has fired. This indicates a bug in FSF GNAT 4.3.2.

--------------------

with Ada.Text_IO;
with Alarm_Clock;

procedure Main is
   My_Alarm : Alarm_Clock.Alarm_Type;
begin
   Ada.Text_IO.Put_Line ("Starting alarm ...");
   My_Alarm.Start;

   Ada.Text_IO.Put_Line ("Waiting for alarm ...");
   My_Alarm.Wait_For_Wakeup;

   Ada.Text_IO.Put_Line ("ALARM!!");
end Main;

--------------------

with Ada.Real_Time.Timing_Events;

package Alarm_Clock is

   use Ada.Real_Time;

   protected type Alarm_Type is
      procedure Start;
      procedure Wakeup (Event : in out Timing_Events.Timing_Event);
      entry Wait_For_Wakeup;
   private
      Timer       : Timing_Events.Timing_Event;
      Alarm_Fired : Boolean := False;
   end Alarm_Type;

end Alarm_Clock;

--------------------

package body Alarm_Clock is

   protected body Alarm_Type is
      procedure Start is
      begin
         Timer.Set_Handler (In_Time => Seconds (3),
                            Handler => Wakeup'Access);
      end Start;

      procedure Wakeup (Event : in out Timing_Events.Timing_Event) is
      begin
         Alarm_Fired := True;
      end Wakeup;

      entry Wait_For_Wakeup when Alarm_Fired is
      begin
         null;
      end Wait_For_Wakeup;
   end Alarm_Type;

end Alarm_Clock;

--------------------

Avoiding the usage of Ada.Real_Time.Timing_Events by implementing a
delaying task does not solve the problem. So it's not Ada real time related.

We suspect that the Alarm_Fired-barrier of the Wait_For_Wakeup entry is
not correctly re-evaluated after the Wakeup()-handler has been called.

Switching the compiler is a solution we consider as last resort.

Does anybody know what the actual problem could be? Is there a different
way to implement the same functionality or a "workaround" which would
avoid this problem?

Thanks in advance,
- reto