A question about task's select delay alternative

A question about task's select delay alternative

[NiGHTS]

In a task with a select like this...

task body X is
begin
    loop
        select
            accept Y;
        or
            delay 10.0;
            exit;
        end select;
    end loop;
end X;

What does "delay" actually do to the CPU? In this case I am using the Adacore GNAT compiler for a PC. Is it a loop constantly evaluating elapsed time? Or is it some kind of timed interrupt?

Thanks for your feedback!

Re: A question about task's select delay alternative

[Jeffrey R. Carter]

On 04/23/2018 07:32 PM, NiGHTS wrote:
> 
> What does "delay" actually do to the CPU? In this case I am using the Adacore GNAT compiler for a PC. Is it a loop constantly evaluating elapsed time? Or is it some kind of timed interrupt?

What timed selective accept "does to the CPU" is not defined by the language. 
It's determined by the compiler implementation and, probably, by the features of 
the OS, if any. So there's no Ada answer to your question.

I don't know how GNAT implements this, but my experience with it is that blocked 
tasks don't use significant CPU. You can test this easily enough.

Why do you care?

-- 
Jeff Carter
"When danger reared its ugly head, he bravely
turned his tail and fled."
Monty Python and the Holy Grail
60

Re: A question about task's select delay alternative

[NiGHTS]

On Monday, April 23, 2018 at 2:06:28 PM UTC-4, Jeffrey R. Carter wrote:
> On 04/23/2018 07:32 PM, NiGHTS wrote:
> > 
> > What does "delay" actually do to the CPU? In this case I am using the Adacore GNAT compiler for a PC. Is it a loop constantly evaluating elapsed time? Or is it some kind of timed interrupt?
> 
> What timed selective accept "does to the CPU" is not defined by the language. 
> It's determined by the compiler implementation and, probably, by the features of 
> the OS, if any. So there's no Ada answer to your question.
> 
> I don't know how GNAT implements this, but my experience with it is that blocked 
> tasks don't use significant CPU. You can test this easily enough.
> 
> Why do you care?
> 
> -- 
> Jeff Carter
> "When danger reared its ugly head, he bravely
> turned his tail and fled."
> Monty Python and the Holy Grail
> 60

I have a number of busy threads I plan on launching, and I am wondering what cost I would incur launching them in parallel with watchdog threads. They are used to monitor the busy threads for performance faults and have fail alternatives if the threads take too long. 

I'd hate to bog down the CPU with unnecessary delays. Do I need to worry about lowering the CPU priority of such a non-essential thread in order to improve overall system performance?

Re: A question about task's select delay alternative

[Dmitry A. Kazakov]

On 2018-04-23 19:32, NiGHTS wrote:
> In a task with a select like this...
> 
> task body X is
> begin
>      loop
>          select
>              accept Y;
>          or
>              delay 10.0;
>              exit;
>          end select;
>      end loop;
> end X;
> 
> What does "delay" actually do to the CPU? In this case I am using the Adacore GNAT compiler for a PC. Is it a loop constantly evaluating elapsed time? Or is it some kind of timed interrupt?

On most systems there is a way to do it in a non-busy manner. E.g. by 
waiting for a system waitable object with 10s timeout under Windows or 
doing same with a futex under Linux or by using pthreads API, whatever 
pleases the Ada RTS provider. When the entry is accepted/completed by 
the task scheduler, the object is signaled. Otherwise the timeout is 
expired and the thread is released with a different return code. In 
short, do not worry.

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

Re: A question about task's select delay alternative

[NiGHTS]

On Monday, April 23, 2018 at 4:40:30 PM UTC-4, Dmitry A. Kazakov wrote:
> On 2018-04-23 19:32, NiGHTS wrote:
> > In a task with a select like this...
> > 
> > task body X is
> > begin
> >      loop
> >          select
> >              accept Y;
> >          or
> >              delay 10.0;
> >              exit;
> >          end select;
> >      end loop;
> > end X;
> > 
> > What does "delay" actually do to the CPU? In this case I am using the Adacore GNAT compiler for a PC. Is it a loop constantly evaluating elapsed time? Or is it some kind of timed interrupt?
> 
> On most systems there is a way to do it in a non-busy manner. E.g. by 
> waiting for a system waitable object with 10s timeout under Windows or 
> doing same with a futex under Linux or by using pthreads API, whatever 
> pleases the Ada RTS provider. When the entry is accepted/completed by 
> the task scheduler, the object is signaled. Otherwise the timeout is 
> expired and the thread is released with a different return code. In 
> short, do not worry.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Thank you for your input. I worry too much.

Re: A question about task's select delay alternative

[reinert]

I have had some success using entries with barriers for avoiding bogging down the computer.

reinert

On Monday, April 23, 2018 at 8:25:39 PM UTC+2, NiGHTS wrote:
> On Monday, April 23, 2018 at 2:06:28 PM UTC-4, Jeffrey R. Carter wrote:
> > On 04/23/2018 07:32 PM, NiGHTS wrote:
> > > 
> > > What does "delay" actually do to the CPU? In this case I am using the Adacore GNAT compiler for a PC. Is it a loop constantly evaluating elapsed time? Or is it some kind of timed interrupt?
> > 
> > What timed selective accept "does to the CPU" is not defined by the language. 
> > It's determined by the compiler implementation and, probably, by the features of 
> > the OS, if any. So there's no Ada answer to your question.
> > 
> > I don't know how GNAT implements this, but my experience with it is that blocked 
> > tasks don't use significant CPU. You can test this easily enough.
> > 
> > Why do you care?
> > 
> > -- 
> > Jeff Carter
> > "When danger reared its ugly head, he bravely
> > turned his tail and fled."
> > Monty Python and the Holy Grail
> > 60
> 
> I have a number of busy threads I plan on launching, and I am wondering what cost I would incur launching them in parallel with watchdog threads. They are used to monitor the busy threads for performance faults and have fail alternatives if the threads take too long. 
> 
> I'd hate to bog down the CPU with unnecessary delays. Do I need to worry about lowering the CPU priority of such a non-essential thread in order to improve overall system performance?