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!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: RFC: Prototype for a user threading library in Ada Date: Fri, 8 Jul 2016 23:17:49 +0300 Organization: Tidorum Ltd Message-ID: References: <58b78af5-28d8-4029-8804-598b2b63013c@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net QImCGGyAdzx/uh89hFjXpQqAgezohrFS4ccZjq3rt3RfFJR6h3 Cancel-Lock: sha1:l5jgC26ijduLQ+0BHAKj6fSOSc0= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:31041 Date: 2016-07-08T23:17:49+03:00 List-Id: On 16-07-08 03: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). 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 currently working on a project which has one response deadline of 1 ms and a main cyclic task that runs with 2 ms period -- but Dmitry bested this with 0.2 ms ... Clearly such applications require a certain level of real-time performance from the computer, but at or above that performance threshold the proper use of priorities does allow a portable implementation, at least with a "bare-metal" RTS. > I'm unconvinced that the way to ensure that "urgent activies" are done is > some sort of magic (and priorities are essentially magic). Magic? Priority-based scheduling and schedulability analysis have been studied and developed scientifically and mathematically for a long time, with ever more powerful methods and tools becoming available to prove that all deadlines are met under all circumstances. Is the Pythagorean Theorem 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. I fully share Dmitry's abhorrence of such manual, distributed scheduling. It would definitely be awful in my domain. To Dmitry's comments I add that it would make it harder to share/reuse SW components between projects, because the proper density of Yields in the shared/reused code would often depend on the real-time architecture of the application that uses the code. Moreover, a Yield is not allowed in a protected operation, but in an application with a large range of deadlines some protected operations, at low priorities, may be long enough that they must be preempted by higher-priority tasks. Long ago, I wrote a couple of cooperative, priority-based multi-taskers, one for the HP2100 16-bit minicomputer and another for the TRS-80 PC (Zilog Z80 processor), in which equivalents of Yield were used. These systems worked and were usable in small applications, with a small number of tasks and a small number of priority levels, but I would certainly not like to base my current applications on such schedulers, and I believe that even my customers would object. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .