GNAT Task Scheduling in Linux

GNAT Task Scheduling in Linux

[Manuel Carro]

    Hello.  I have a question regarding the (default) task scheduling
policy of GNAT (3.13p) in Linux.  I have a simple program which starts
some tasks which increment a nonprotected variable.  The tasks should
start (almost) at once, so that the variable is incremented
concurrently (and wrongly), and the problem is that every task is
started only after another task has finished.  Hence, the problem of
concurrent access does not show up.

    Changing the adalib and adainclude links in the distribution from
rts-sfu to rts-native solved the issue: the different tasks start
(almost) at once.  The question is if there is any way to force the
latter behavior *without* fiddling around with the links.  I am not
terribly worried about performance, because we will use Ada as an
educational tool in an academic environment.

    Thanks a lot in advance.


-- 
          ||            Manuel Carro -- DLSIIS            ||
          ||           e-mail: mcarro@fi.upm.es           ||
          ||      http://lml.ls.fi.upm.es/~boris          ||
          ||    http://clip.dia.fi.upm.es/Software/Ciao   ||
          || Phone: +34 91 336-7455  FAX: +34 91 336-7412 ||

Re: GNAT Task Scheduling in Linux

[Ted Dennison]

In article <7sbsn966zs.fsf@salmon.ls.fi.upm.es>, Manuel Carro says...
>    Hello.  I have a question regarding the (default) task scheduling
>policy of GNAT (3.13p) in Linux.  I have a simple program which starts
>some tasks which increment a nonprotected variable.  The tasks should
>start (almost) at once, so that the variable is incremented
>concurrently (and wrongly), and the problem is that every task is
>started only after another task has finished.  Hence, the problem of
>concurrent access does not show up.

I belive the FSU threads were designed to allow validation of the Ada compiler.
As such, they follow the priority scheduling clause of the real-time annex (LRM
D.2) to the letter. In particular, it implements the FIFO_Within_Priorities task
dispatching policy, and follows the rules set out in D.2.1 for switching at
"task dispatching points". The language only defines such points to be "delay"
statements, rendezvous, and the changing of the running task's priority, if I
read it right. If they only implemented the minimum required to conform with the
LRM, then you can't exepect to see task switches at any other time.

You might try making one of the tasks higher priority, and having it put itself
to sleep with "delay" statements before a variable update. That way its possible
that the delay might expire, forcing the start of the higher-priority task,
during an update to the variable in the lower-priority task. It'd be hit-or-miss
causing an actual invalid update this way, but these are always hit-or-miss
types of errors.


---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com