From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: GNAT and Tasklets Date: Wed, 17 Dec 2014 16:08:20 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <455d0987-734a-4505-bb39-37bfd1a2cc6b@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1418854106 5946 24.196.82.226 (17 Dec 2014 22:08:26 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 17 Dec 2014 22:08:26 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:24078 Date: 2014-12-17T16:08:20-06:00 List-Id: "Niklas Holsti" 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.