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!news.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: Thu, 7 Jul 2016 19:03:36 -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 1467936213 11865 24.196.82.226 (8 Jul 2016 00:03:33 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 8 Jul 2016 00:03:33 +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:31036 Date: 2016-07-07T19:03:36-05:00 List-Id: "Niklas Holsti" wrote in message news:du69ugF3631U1@mid.individual.net... > On 16-07-07 03:32 , Randy Brukardt wrote: >> "Dmitry A. Kazakov" wrote in message >> news:nliir0$1a7l$1@gioia.aioe.org... >>> On 05/07/2016 23:53, Randy Brukardt wrote: >> ... >>>> Nothing in the core language of Ada requires tasks to be pre-emptive. >>> >>> Some applications rely on time sharing and most do on close to instant >>> switching to a task of higher priority. >> >> Priorities are evil and almost always used poorly, that is to do >> something >> that should be accomplished explicitly with locking or the like. No >> system >> I'm contemplating has any priorities. > > 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). 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'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. [Most of the cases have involved I/O, and the system I've been discussing with Dmitry would pretty much have eliminated that. We had considered adding synchronization points to loops many years back, but couldn't figure out how to do that cheaply enough to be useful (the MS-DOS clock was much too expensive) - that could be revisited if necessary]. It might actually be possible to make this system work with some form of priorities (we have them in our task supervisor, we just have the range of priorities set to 1 so that preemption doesn't come into play). That would certainly require the compiler to break loop and call cycles with synchronization points, and whether that could be done without visible performance impact is definitely TBD. (And I don't want to make my head hurt worrying about priorities when just getting task mapping to work is complex enough.) Randy.