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:nlj244$43i$1@gioia.aioe.org...
> On 05/07/2016 23:24, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
...
>> I'd look at replacing:
>>      Read (Handle, Data, Last);
>> with something like:
>>      loop
>>          if Ready (Handle) then
>>              Read_Ready_Data (Handle, Data, Last);
>>              exit if Last > Data'Last;
>>          end if;
>>          Yield;
>>      end loop;
>
> This is in order of several magnitudes slower because after yield to 
> return back not before next time slot, e.g. timer interrupt. It is no 
> different from polling.

That's actually an advantage, as it greatly decreases the possibility that 
this task will waste time retrying repeatedly. And it is very rare that it 
would matter (assuming that I/O is properly buffered), as the vast majority 
of I/O will run at full speed, and that which doesn't is very slow 
(relatively speaking) anyway. (i.e., you're waiting for a packet to come 
across a network -- that's a long time -- usually tenths of seconds --  
compared to the slot time.)

Finally, our task supervisor doesn't use slots, and I've spent quite a bit 
of effort avoiding the use of Sleep in Windows such that it would take 
longer than the next delay expiration. It wouldn't be good for a low-power 
application, but I doubt any tasking system would be there.

> Bit even if RTS had proper drivers on top of the system ones it would 
> still greatly slower in most case.

Disagree. My experience with Internet servers is that one can and should use 
relatively long delays in I/O without hurting response times. I think files 
would be similar (although the delays would be smaller). No way to tell for 
sure without building some examples.

...
>>> Well, the difference is that Inline can be safely ignored. Limitation on
>>> the task number cannot be.
>>
>> Same either way - we're "just" talking about performance.
>
> Unless the system limit on the number of physical threads apply.

That would never happen.

> And the situation is reverse. With inlining you may fail at compile time 
> with GNAT when it runts out of memory, and it is recoverable error since 
> you can forbid inlining.

Usually, compilers just don't inline in such circumstances, and no one 
really cares unless they happen to look at a machine code listing. (Since 
the inlining probably didn't make much difference in the first place.) 
Inline is a suggestion, not a promise (much like Suppress). There's never a 
reason to treat such things as commands.

[Yes, one of the reasons RR doesn't have the sort of customer base that 
AdaCore has is that I'm not willing to implement stupid stuff just because 
some customers are confused. :-)]

> With mapping tasks to threads you fail at run-time, and there is nothing 
> you can do to prevent that from happening.

Certainly not: the threads are all created at program-startup (5 threads for 
4 cores, I think), and the number doesn't change after that, unless one 
calls the library routine for that purpose. That would be a very rare thing, 
and failure wouldn't cause the program to fail, just run slower. An OS that 
didn't allow as many threads as there are cores isn't going to work for this 
system anyway, so the compiler would never exist in the first place. (So 
you'd get your compile-time detection.)

No language-defined I/O (or the sockets library, for that matter) would use 
blocking I/O. User-defined code could, of course, call blocking I/O (that 
being the main reason to allow more threads to be added manually). But it 
would be strongly discouraged.

                                        Randy.