From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,a4db0fc323f0b09e,start X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!ecngs!feeder2.ecngs.de!feeder.erje.net!feeder.eternal-september.org!eternal-september.org!not-for-mail From: Reto Buerki Newsgroups: comp.lang.ada Subject: Barrier re-evaluation issue with GNAT 4.3.2 Date: Thu, 24 Sep 2009 19:02:14 +0200 Organization: A noiseless patient Spider Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: news.eternal-september.org U2FsdGVkX1+qKWSLabVQfwzC5TIyEs/Z/ISmaI9DDoRCrWh/akfd09gkfsvNlOBRLVp9hbBU+DMNhetpKluRSM60YTI7fAE36AFhQijnK/CWW+LZzO2gVXbfZZnzC3is7iqD9ldHWKs= X-Complaints-To: abuse@eternal-september.org NNTP-Posting-Date: Thu, 24 Sep 2009 17:02:07 +0000 (UTC) X-Auth-Sender: U2FsdGVkX1/PZwGYI5YAIiMaCHX5XaW2 Cancel-Lock: sha1:7CeMcHtY+/Ust77Xw7Dl5JPTRJU= User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) Xref: g2news2.google.com comp.lang.ada:8458 Date: 2009-09-24T19:02:14+02:00 List-Id: 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