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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no 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!news2.euro.net!newsfeed.freenet.de!bolzen.all.de!newsfeed.ision.net!newsfeed2.easynews.net!ision!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Barrier re-evaluation issue with GNAT 4.3.2
Newsgroups: comp.lang.ada
User-Agent: 40tude_Dialog/2.0.15.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
References: <h9g8mf$v4f$1@news.eternal-september.org>
Date: Thu, 24 Sep 2009 19:47:44 +0200
Message-ID: <qheeig65rowe.1x18w150lpl1q.dlg@40tude.net>
NNTP-Posting-Date: 24 Sep 2009 19:47:40 CEST
NNTP-Posting-Host: 4e146f45.newsspool3.arcor-online.net
X-Trace: 
 DXC=h:\A5TDJ^F7lIh70@<QIE7McF=Q^Z^V384Fo<]lROoR1^YC2XCjHcb9LZCG]_69gT3DNcfSJ;bb[5IRnRBaCd<M>5MDL0Tdg0Y3BW`J@9U=oQ7
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:8459
Date: 2009-09-24T19:47:40+02:00
List-Id: <comp.lang.ada>

On Thu, 24 Sep 2009 19:02:14 +0200, Reto Buerki 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.

It also works under GNAT Pro 6.2.1.

[...]

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

Switching to a never version looks plausible to me.
 
> 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?

I was always wondering the rationale behind introducing
Ada.Real_Time.Timing_Events. The delay statement does the very same thing:

with Ada.Real_Time;  use Ada.Real_Time;
   ...
   Event : Time;
begin
   ...
   Put_Line ("Starting alarm ...");
   Event := Clock + To_Time_Span (3.0);

   Put_Line ("Waiting for alarm ...");
   delay until Event;
   Put_Line ("ALARM!!");

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de