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
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news4.google.com!feeder.news-service.com!de-l.enfer-du-nord.net!gegeweb.org!aioe.org!nospam
From: "John B. Matthews" <nospam@nospam.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Barrier re-evaluation issue with GNAT 4.3.2
Date: Fri, 25 Sep 2009 11:56:46 -0400
Organization: The Wasteland
Message-ID: <nospam-E7CE69.11564625092009@news.aioe.org>
References: <h9g8mf$v4f$1@news.eternal-september.org>
NNTP-Posting-Host: LQJtZWzu+iKlBROuDg+IUg.user.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
X-Notice: Filtered by postfilter v. 0.8.0
Cancel-Lock: sha1:OK74SFknEpyvAiWmuAlPBxZ17fg=
User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X)
Xref: g2news2.google.com comp.lang.ada:8467
Date: 2009-09-25T11:56:46-04:00
List-Id: <comp.lang.ada>

In article <h9g8mf$v4f$1@news.eternal-september.org>,
 Reto Buerki <reet@codelabs.ch> wrote:

> 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.

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.

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;

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

package Alarm_Clock is

   use Ada.Real_Time;

   protected type Alarm_Type is
      entry Wait;
      entry Signal;
      procedure Start;
      procedure Wakeup(Event : in out Timing_Events.Timing_Event);

   private
      entry Reset;
      Alarm : Boolean := False;
   end Alarm_Type;

end Alarm_Clock;

package body Alarm_Clock is

   Timer : Timing_Events.Timing_Event;

   protected body Alarm_Type is

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

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

      entry Wait when Alarm is
      begin
         null;
      end Wait;

      entry Signal when True is
      begin
         if Wait'Count > 0 then
            Alarm := True;
            requeue Reset;
         end if;
      end Signal;

      entry Reset when Wait'Count = 0 is
      begin
         Alarm := False;
      end Reset;

   end Alarm_Type;

end Alarm_Clock;

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>