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!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: RFC: Prototype for a user threading library in Ada Date: Fri, 8 Jul 2016 09:32:55 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <58b78af5-28d8-4029-8804-598b2b63013c@googlegroups.com> NNTP-Posting-Host: vZYCW951TbFitc4GdEwQJg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:31037 Date: 2016-07-08T09:32:55+02:00 List-Id: On 08/07/2016 02:03, Randy Brukardt wrote: > "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). Some of our customers have 0.2ms response time requirement and that not just local but over the network. > 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 don't see why. Any reasonable implementation would do. An implementation that does not preempt lower priority tasks is not reasonable. If you wanted to push the argument you would end up with disabling hardware interrupts. > 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. No it does not and it is a *very* bad design, because it distributes making the decision to switch to the parts of the software which must know nothing about the reason when switching is necessary. E.g. that a task solving some differential equation decides whether to switch to the keyboard interrupt handler. That belongs to the keyboard driver, not to the equation solver. Yield is a premature optimization of worst kind and I bet it is highly inefficient comparing to preemptive scheduling on any modern hardware. It is just like arguing for return codes over exceptions. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de