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

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

On 2016-07-11 21:40, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:nlnl0b$93q$1@gioia.aioe.org...

>>> 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.
>
> Your definition of reasonable and mine are obviously incompatible. Hardware
> interrupts are evil; possibly a necessary evil but still evil and one wants
> to minimize them as much as possible. Obviously you disagree.

What is evil in hardware interrupts? It is a piece of hardware serving 
certain purpose. There is no moral component there from the software 
developing POV, especially because no alternative solution ever existed.

>>> 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.
>
> Wrong. In this scheme *all* software switches, all the time. Only the task
> supervisor is making any decisions, but it is getting the opportunity to do
> so at reasonable intervals. Neither the keyboard nor the diffy-Q solver has
> anything to do with it.

The keyboard driver is at the receiving end, as a subscriber to the 
interrupt, or keyboard event. Solver and other tasks sharing the 
processor have nothing to do with that. Whether all events must be 
routed through the supervisor is an implementation detail. In any case 
the supervisor is not a part of the software, it is an OS/RTS component, 
thus non-existent from the SW design POV.

> I agree that having to put in such choices manually isn't a good idea, but I
> wasn't suggesting that (outside of user-written I/O that doesn't use
> language-defined or implementation-defined libraries). The compiler would do
> it at appropriate points.

How is that different then? If the compiler inserts re-scheduling code 
after each few instructions, that logically is *exactly* same as 
re-scheduling at timer interrupts, except than incredibly inefficient. 
This would be nothing but poor-man's preemptive scheduling.

My point was that we need non-preemptive user-controlled (explicit, 
cooperative) scheduling of certain tasks on top of the standard schema. 
And this looks much simpler to implement than code insertions you suggested.

>> It is just like arguing for return codes over exceptions.
>
> Given that almost none of this is visible to the Ada user, I don't see the
> analogy. (And certainly, return codes are much more efficient than
> exceptions; the problem is the distribution of concerns. That's not
> happening here.)

The analogy is that instead of signaling an event (exception, scheduling 
event) at its source with the advantage of hardware acceleration, you 
poll for the event state all over the code. Doing that you lose hardware 
support and you have a huge problem with third party libraries that does 
succumb to your schema.

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