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!gegeweb.org!news.ecp.fr!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: RFC: Prototype for a user threading library in Ada Date: Tue, 5 Jul 2016 16:53:03 -0500 Organization: JSA Research & Innovation Message-ID: References: <58b78af5-28d8-4029-8804-598b2b63013c@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1467755580 1317 24.196.82.226 (5 Jul 2016 21:53:00 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 5 Jul 2016 21:53:00 +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:31024 Date: 2016-07-05T16:53:03-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:nl84rj$h70$1@gioia.aioe.org... > On 2016-07-02 06:13, Randy Brukardt wrote: > >> Seriously, I'm thinking that thread scheduling overhead could be >> reduced/eliminated by the task supervisor, and thus there's no real >> problem >> with writing Ada tasks this way -- except of course that existing >> implementations don't try to do this sort of optimization. > > There could be OS limitations on the number of threads a process may have. It would be weird if one couldn't have as many threads as there are cores. (And if not, then one has to have more processes rather than more threads.) > I was thinking about "user-scheduled" tasks, which are not scheduled at > all. Some user task explicitly releases one task from the pool and gets > control back when that task calls to an entry. Yes, that's how all tasks work in Janus/Ada. > The important point I believe is preemption. "User-scheduled" tasks would > not be required to be preemptive. Nothing in the core language of Ada requires tasks to be pre-emptive. I believe any such requirement is a mistake, one that the runtime I'm talking about isn't going to make. (I.e., the Janus/Ada runtime doesn't support preemption, and that's very unlikely to change even when multiple threads get involved.) Such an implementation can't meet some of the default requirements of Annex D; that's another reason for an aspect to be involved (to say that Annex D doesn't apply). But of course there's no requirement to implement any SNA (such as Annex D) to implement Ada. There's a reason these things are separate! Randy.