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=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,9983e856ed268154 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.205.139.2 with SMTP id iu2mr62795bkc.7.1345705360559; Thu, 23 Aug 2012 00:02:40 -0700 (PDT) Received: by 10.180.103.197 with SMTP id fy5mr110790wib.1.1345705360099; Thu, 23 Aug 2012 00:02:40 -0700 (PDT) Path: m12ni128347bkm.0!nntp.google.com!news2.google.com!yt1no40993544wib.1!news-out.google.com!q11ni254263629wiw.1!nntp.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Should Inline be private in the private part of a package spec? Date: Thu, 23 Aug 2012 10:02:37 +0300 Organization: Tidorum Ltd Message-ID: References: <501bd285$0$6564$9b4e6d93@newsspool4.arcor-online.net> <502005b6$0$9510$9b4e6d93@newsspool1.arcor-online.net> <50203ca2$0$9512$9b4e6d93@newsspool1.arcor-online.net> <502040c0$0$9510$9b4e6d93@newsspool1.arcor-online.net> <50677fa2-7f82-4ccc-8c56-161bf67fefe1@googlegroups.com> Mime-Version: 1.0 X-Trace: individual.net 6VYN6rwbt7SUG1VyjKkgSwceqDls/3FjpziOGxXgkSiup4KSZ6JiHaqOGA+gkHvLrW Cancel-Lock: sha1:gfnoHKGMhvayP+WHcsS5TCJUNn4= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Date: 2012-08-23T10:02:37+03:00 List-Id: On 12-08-23 01:08 , Randy Brukardt wrote: > "Vasiliy Molostov" wrote in message > news:op.wje1nc1hka8ora@aspire.local... > Randy Brukardt ?????(?) ? ????? ?????? Wed, 22 Aug > 2012 02:31:22 +0400: >>> Maybe, but it all sounds like a fantasy to me. (Much about XML sounds >>> like pure fantasy to me.) >> >> Yep, like tasking in '80-90. It was a pure fantasy. But useful. > > Surely it was a fantasy back then, but it was definitely not useful for > anything beyond toy programs. I disagree. In that time interval I implemented useful real-time systems using tasking with DEC Ada on MicroVAX/VMS. They were not large programs, but they were production programs, not toys. Tasking worked well for me in that environment. > Certainly not on PCs. It took until the > Windows 95 era for CPUs to be powerful enough to justify the headaches that > it introduced. The blame is probably due to the "toy" nature of early PCs and Windows. "Real" computers were easily running multi-program, multi-threading workloads at that time. Multi-threading real-time kernels for embedded systems were well established, too. > One the problems for Janus/Ada is that we designed our tasking system mainly > so that we could pass validation. There was no attempt at efficiency or > usability simply because it was a silly thing to use at the time (late > 1980s). So there were some design flaws that have made it hard to adapt to > more modern systems where tasking actually has value. What kind of "value" are you thinking of? Increased performance through parallel execution on multiple cores? Don't you agree that tasking also is a valuable tool for the implementation of concurrent programs on single cores? For the programs that I mentioned at the top of this post, the users saw significant real-time performance improvements through concurrent operation of peripherals and the ability to continue application functions (especially data acquisition functions) without breaks. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .