Re: GNAT and Tasklets

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

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:cfe7hnFaj8oU1@mid.individual.net...
> On 14-12-17 15:06 , vincent.diemunsch@gmail.com wrote:
...
>> and since User Level threads are lightweight
>> compared to Kernel threads,
>
> My impression is that this is no longer the case, but perhaps things have 
> changed again in recent years.
>
>> But with multiple cores, we need all tasks running on a pool of
>> kernel threads, one thread per core.
>
> In what way would that be better than having one kernel thread per task? 
> In either case, each task would have to have its own stack area, and I 
> don't see why task switching would be radically faster, either (assuming 
> that these kernel threads share the same virtual memory space).

I don't agree. We did experiments on this back in the early days of Windows 
XP, and the Janus/Ada implementation (cooperative tasks) was several times 
faster than the threaded implementations of other compilers tested. As such, 
we didn't pursue a threaded implementation at that time. (Obviously, we 
didn't anticipate multicore machines at that time.)

While I'm sure that OS threads have less overhead now, they'll always be 
behind since they have to save a lot more stuff during a task switch. Since 
a task switch mainly happens when a task routine is called (a task 
dispatching point in Ada parlence), and we can make sure that little needs 
to be saved in that case (nothing is in registers, for instance), task 
switches could be very fast. (They're not anywhere near as fast as they 
could be for historical reasons.)

(It's the same reason that preemption would be much slower in our 
implementation than normal task switching. That doesn't matter since we 
don't support any priorities; priorities don't really work on multicore 
anyway since tasks generally don't migrate so it is best that programmers 
live without them.)

I've considered looking into building a task supervisor based on 
work-stealing, which would only use a small number of OS threads (probably 
one per core). That would would make better use of the unique aspects of Ada 
tasks, but I worry that it wouldn't be compatible with C++ and the like 
(sadly, a business requirement these days).

> As I remember, the user-level thread solution in GNAT had the drawback 
> that if one thread blocked on an OS call, the whole program was blocked.

True, but that's not a real problem in most software (that has to respond in 
human timescales - if you need microsecond response times, forget 
Janus/Ada!). It requires a bit of care to avoid waiting on anything that 
could block for a long time (typically reads of some sort), but most OS 
operations happen fast enough that you can't notice them.

After all, Claw programs work (including those with multiple tasks 
displaying in a window) essentially the same when compiled with Janus/Ada, 
or with GNAT, or with the old Rational compiler. The tasking model doesn't 
matter to Claw. Similarly, our web server and mail filter both work fine 
with the Janus/Ada implementation and I'll soon be porting them to Gnat on 
Linux - I expect them to work fine there, too.

                           Randy.