comp.lang.ada
 help / color / mirror / Atom feed
* Synchronization: delays x hardware timers
@ 2013-04-26 15:27 Rego, P.
  2013-04-26 16:03 ` Dmitry A. Kazakov
  2013-04-26 17:22 ` Jeffrey Carter
  0 siblings, 2 replies; 3+ messages in thread
From: Rego, P. @ 2013-04-26 15:27 UTC (permalink / raw)


Dear friends,

I would very appreciate your opinions about synchronization. I have a global (static) variable which is send periodically over the communication media and a flag is checked each cycle to get the equipment response about that sent message. In this case, two different flags must be sent in order to have the correct response.

So I have an asynchronous call to a procedure Request_Action:

Global_Flag := Flag_Type; -- This is sent periodically.
procedure Request_Action is
   Initial_Response : Response_Type := Get_Response; -- which is /= NULL_RESPONSE
   Updated_Response : Response_Type := NULL_RESPONSE; -- NULL_RESPONSE is constant
   
   while Updated_Response < Initial_Response loop
      Global_Flag := FIRST_FLAG; -- Now I should wait for the response to be ready
      <Process_Wait>;
      Global_Flag := SECOND_FLAG; -- Now I should wait again.
      <Process_Wait>;

      Updated_Response := Get_Response;
   end loop;
end Request_Action;

The question is which is the best way to implement the <Process_Wait>. The application is soft real-time and I just need to ensure that Global_Flag to be processed before the next cycle begins. Also, I need to use only Ada 95.

I think that if I use a simple delay it's very enough; and since I do not have a hard real-time deadline, I even do not need to use delay until. A coleague argued with me saying that I must use hardware timers any case. Personally I think it's an unnecessary use of hardware resources.

I would simply code this as 
   delay CYCLE_TASK + CYCLE_DELTA;

Thus, what is your opinion?

Thanks very much.



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Synchronization: delays x hardware timers
  2013-04-26 15:27 Synchronization: delays x hardware timers Rego, P.
@ 2013-04-26 16:03 ` Dmitry A. Kazakov
  2013-04-26 17:22 ` Jeffrey Carter
  1 sibling, 0 replies; 3+ messages in thread
From: Dmitry A. Kazakov @ 2013-04-26 16:03 UTC (permalink / raw)


On Fri, 26 Apr 2013 08:27:39 -0700 (PDT), Rego, P. wrote:

> The question is which is the best way to implement the <Process_Wait>.

Calling an entry of a protected object (waitable event object) or else
doing it synchronously from a callback.

> I think that if I use a simple delay it's very enough; and since I do not
> have a hard real-time deadline, I even do not need to use delay until. A
> coleague argued with me saying that I must use hardware timers any case.
> Personally I think it's an unnecessary use of hardware resources.

Which is not different from delay. When a task does delay it is put to
sleep to be awaken by the scheduler. The scheduler is triggered by a timer
interrupt.

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



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Synchronization: delays x hardware timers
  2013-04-26 15:27 Synchronization: delays x hardware timers Rego, P.
  2013-04-26 16:03 ` Dmitry A. Kazakov
@ 2013-04-26 17:22 ` Jeffrey Carter
  1 sibling, 0 replies; 3+ messages in thread
From: Jeffrey Carter @ 2013-04-26 17:22 UTC (permalink / raw)


On 04/26/2013 08:27 AM, Rego, P. wrote:
>
> Thus, what is your opinion?

Do it the simple, clear way, and measure the result. If it meets the timing 
requirements, use it.

-- 
Jeff Carter
"My legs are gray, my ears are gnarled, my eyes are old and bent."
Monty Python's Life of Brian
81



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-04-26 17:22 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-26 15:27 Synchronization: delays x hardware timers Rego, P.
2013-04-26 16:03 ` Dmitry A. Kazakov
2013-04-26 17:22 ` Jeffrey Carter

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox