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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 08/07/2016 02: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).

Some of our customers have 0.2ms response time requirement and that not 
just local but over the network.

> 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 don't see why. Any reasonable implementation would do. An 
implementation that does not preempt lower priority tasks is not 
reasonable. If you wanted to push the argument you would end up with 
disabling hardware interrupts.

> I'm unconvinced that the way to ensure that "urgent activies" are done is
> some sort of magic (and priorities are essentially 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.

No it does not and it is a *very* bad design, because it distributes 
making the decision to switch to the parts of the software which must 
know nothing about the reason when switching is necessary. E.g. that a 
task solving some differential equation decides whether to switch to the 
keyboard interrupt handler. That belongs to the keyboard driver, not to 
the equation solver.

Yield is a premature optimization of worst kind and I bet it is highly 
inefficient comparing to preemptive scheduling on any modern hardware. 
It is just like arguing for return codes over exceptions.

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