Re: RE: Timing events in GNAT GPL 2006

Re: RE: Timing events in GNAT GPL 2006

[Rolf Ebert]

> There are three things wrong with your codes. Two of them are critical.
> 1. The protected procedure Inc_Clock has wrong parameter mode. It must
> be in out mode.
> 2. The call Set_Handler from the protected procedure will result in a
> deadlock it is run.
> 3. Protected object must be declared at the library level. Yours is not.
> As the result, non-local pointer cannot point to local object error at
> lines 20 and 26

OK, I fixed issues 1 and 3 in my code and I can observe issue 2. I don't understand, however, why the deadlock occurs. Is the deadlock required by the RM or is it just due to GNAT's implementation of Timing_Events?

> I designed for both one shot and periodic timers using Timing Event. If
> it is helpful, I will post my code here. Just let me know.

Although I found by now your discussion from around March 2006, I'd like to see your code.

Thanks for your fast response.

   Rolf

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal f�r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

RE: RE: Timing events in GNAT GPL 2006

[Vo, Anh (US SSA)]

-----Original Message-----
From: Rolf Ebert [mailto:rolf.ebert_nospam_@gmx.net] 
Sent: Sunday, January 14, 2007 5:10 AM
To: Vo, Anh (US SSA); comp.lang.ada@ada-france.org
Subject: Re: RE: Timing events in GNAT GPL 2006


<< > There are three things wrong with your codes. Two of them are
critical.
> 1. The protected procedure Inc_Clock has wrong parameter mode. It must
> be in out mode.
> 2. The call Set_Handler from the protected procedure will result in a
> deadlock it is run.
> 3. Protected object must be declared at the library level. Yours is
not.
> As the result, non-local pointer cannot point to local object error at
> lines 20 and 26

OK, I fixed issues 1 and 3 in my code and I can observe issue 2. I don't
understand, however, why the deadlock occurs. Is the deadlock required
by the RM or is it just due to GNAT's implementation of Timing_Events?
>>

This deadlock occurred when I tested it. I was supposed to find out why?
But, I have not had a chance to investigate it yet.  

<< > I designed for both one shot and periodic timers using Timing
Event. If
> it is helpful, I will post my code here. Just let me know.

Although I found by now your discussion from around March 2006, I'd like
to see your code. >>

To break the deadlock above, I have to uncouple the action of Event
Handler and Set Handler as shown in the Generic_Timers package.

with Ada.Real_Time.Timing_Events;

generic
   One_Shot : Boolean := True;
   Timer_Name : String := "Generic_Timers";
   For_Duration : in Ada.Real_Time.Time_Span;
   with procedure Action is <>;

package Generic_Timers is

   Timer_Error : exception;

   procedure Start;
   procedure Stop;
   procedure Cancel;

private

   The_Event : Ada.Real_Time.Timing_Events.Timing_Event;

end Generic_Timers;

package body Generic_Timers is

   use Ada;

   task Event_Handoff is
      entry Handoff;
   end Event_Handoff;

   task body Event_Handoff is
   begin
      Longlive :
      loop
         select
            accept Handoff;
            delay 0.0; -- make sure protected operation is completed
before
            Start;     -- starting the next cycle.
         or
            terminate;  -- later alligator
         end select;
      end loop Longlive;
   end Event_Handoff;

   protected Events is
      procedure Handler (Event: in out
Real_Time.Timing_Events.Timing_Event);
   end Events;

   protected body Events is
      procedure Handler (Event: in out
Real_Time.Timing_Events.Timing_Event) is
      begin
         Action;
         Pragma Warnings (Off);
         if not One_Shot then
            Event_Handoff.Handoff;
         end if;
         Pragma Warnings (On);
      end Handler;
   end Events;

   procedure Start is
      use type Ada.Real_Time.Timing_Events.Timing_Event_Handler;
   begin
      if Real_Time.Timing_Events.Current_Handler (The_Event) = null then
         Real_Time.Timing_Events.Set_Handler (
                               The_Event, For_Duration,
Events.Handler'access);
      else
         raise Timer_Error with Timer_Name & " started already";
      end if;
   end Start;

   procedure Stop is
      Success : Boolean := False;
      use type Ada.Real_Time.Timing_Events.Timing_Event_Handler;
   begin
      if Real_Time.Timing_Events.Current_Handler (The_Event) /= null
then
         Real_Time.Timing_Events.Cancel_Handler (The_Event, Success);
         if not Success then
            raise Timer_Error with "fail to cancel " & Timer_Name;
         end if;
      end if;
   end Stop;

   procedure Cancel renames Stop;

end Generic_Timers;

<< Thanks for your fast response >>

You are welcome.

AV

RE: RE: Timing events in GNAT GPL 2006

[Vo, Anh (US SSA)]

-----Original Message-----
From: comp.lang.ada-bounces@ada-france.org
[mailto:comp.lang.ada-bounces@ada-france.org] On Behalf Of Vo, Anh (US
SSA)
Sent: Monday, January 15, 2007 8:30 AM
To: Rolf Ebert; comp.lang.ada@ada-france.org
Subject: RE: RE: Timing events in GNAT GPL 2006

-----Original Message-----
From: Rolf Ebert [mailto:rolf.ebert_nospam_@gmx.net] 
Sent: Sunday, January 14, 2007 5:10 AM
To: Vo, Anh (US SSA); comp.lang.ada@ada-france.org
Subject: Re: RE: Timing events in GNAT GPL 2006


<< > There are three things wrong with your codes. Two of them are
critical.
> 1. The protected procedure Inc_Clock has wrong parameter mode. It must
> be in out mode.
> 2. The call Set_Handler from the protected procedure will result in a
> deadlock it is run.
> 3. Protected object must be declared at the library level. Yours is
not.
> As the result, non-local pointer cannot point to local object error at
> lines 20 and 26

<<<$$$ OK, I fixed issues 1 and 3 in my code and I can observe issue 2.
I don't
understand, however, why the deadlock occurs. Is the deadlock required
by the RM or is it just due to GNAT's implementation of Timing_Events?
>>

This deadlock occurred when I tested it. I was supposed to find out why?
But, I have not had a chance to investigate it yet. $$$>>>

OK, I have some good news to share. The deadlock has been fixed in
GNAT/GCC- 4.3-20070119 on RedHat. Therefore, the handoff task is no
longer needed.

AV