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

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:nlnl0b$93q$1@gioia.aioe.org...
> On 08/07/2016 02:03, Randy Brukardt wrote:
...
>>> 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.

Your customers wouldn't be a candidate for this implementation, then.

>> 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.

>> 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.

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.

> Yield is a premature optimization of worst kind and I bet it is highly 
> inefficient comparing to preemptive scheduling on any modern hardware.

Dunno; it wasn't very efficient on MS-DOS, but the problem there was that 
MS-DOS itself wasn't re-enterant. With multiple threads running at all 
times, the equation is very different.

I don't want to make a claim that it will be better in some sense, the 
experiment has to be done before any answer is known. (Task switching 
appears to be *much* cheaper in this model, so the question remains whether 
that savings makes up for the extra cost.)

> 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.)

                                        Randy.