Re: RFC: Prototype for a user threading library in Ada

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 16-07-08 03:03 , Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
> news:du69ugF3631U1@mid.individual.net...
>> On 16-07-07 03:32 , Randy Brukardt wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:nliir0$1a7l$1@gioia.aioe.org...
>>>> On 05/07/2016 23:53, Randy Brukardt wrote:
>>> ...
>>>>> Nothing in the core language of Ada requires tasks to be pre-emptive.
>>>>
>>>> Some applications rely on time sharing and most do on close to instant
>>>> switching to a task of higher priority.
>>>
>>> Priorities are evil and almost always used poorly, that is to do
>>> something
>>> that should be accomplished explicitly with locking or the like. No
>>> system
>>> I'm contemplating has any priorities.
>>
>> Are you not contemplating any real-time systems? If you are, what do you
>> use instead of priorites, to ensure that urgent activities are done in
>> time?
>
> I'm not contemplating hard-real-time systems (under 10ms response time). I
> don't think it is possible to create implementation-independent code for
> those sorts of deadlines, and as such it doesn't really matter from a
> language perspective how that's done (it won't be portable in any case).

I'm currently working on a project which has one response deadline of 1 
ms and a main cyclic task that runs with 2 ms period -- but Dmitry 
bested this with 0.2 ms ...

Clearly such applications require a certain level of real-time 
performance from the computer, but at or above that performance 
threshold the proper use of priorities does allow a portable 
implementation, at least with a "bare-metal" RTS.

> I'm unconvinced that the way to ensure that "urgent activies" are done is
> some sort of magic (and priorities are essentially magic).

Magic? Priority-based scheduling and schedulability analysis have been 
studied and developed scientifically and mathematically for a long time, 
with ever more powerful methods and tools becoming available to prove 
that all deadlines are met under all circumstances. Is the Pythagorean 
Theorem magic?

> I'd rather make sure that no task is hogging the system, and avoid
> overcommitting. That usually happens naturally, and in the unusual case
> where it doesn't, there's almost always someplace where adding a
> synchronization point (usually a "Yield" aka delay 0.0) fixes the problem.

I fully share Dmitry's abhorrence of such manual, distributed 
scheduling. It would definitely be awful in my domain. To Dmitry's 
comments I add that it would make it harder to share/reuse SW components 
between projects, because the proper density of Yields in the 
shared/reused code would often depend on the real-time architecture of 
the application that uses the code. Moreover, a Yield is not allowed in 
a protected operation, but in an application with a large range of 
deadlines some protected operations, at low priorities, may be long 
enough that they must be preempted by higher-priority tasks.

Long ago, I wrote a couple of cooperative, priority-based multi-taskers, 
one for the HP2100 16-bit minicomputer and another for the TRS-80 PC 
(Zilog Z80 processor), in which equivalents of Yield were used. These 
systems worked and were usable in small applications, with a small 
number of tasks and a small number of priority levels, but I would 
certainly not like to base my current applications on such schedulers, 
and I believe that even my customers would object.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .