Re: Should Inline be private in the private part of a package spec?

["Randy Brukardt" <randy@rrsoftware.com>]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:a9m2seF5clU1@mid.individual.net...
> On 12-08-23 01:08 , Randy Brukardt wrote:
>> "Vasiliy Molostov" <molostoff@gmail.com> wrote in message
>> news:op.wje1nc1hka8ora@aspire.local...
>> Randy Brukardt <randy@rrsoftware.com> ?????(?) ? ????? ?????? 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.

True, there were multitasking machines at the time. But most Ada compilers 
mapped into a single process (the idea of "thread" not having been added to 
most OSes at that time), so you didn't get any of the advantages of that.

>> 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.

Multicore execution, primarily. I do agree that there is value to using 
tasks as a structuring element (they're used extensively in my spam filter 
and web server, for obvious reasons). But back in the 1990s, we had to 
operate much closer to the metal, and the high overhead of tasking 
(especially within a single process tasking) could only be justified in 
programs with quite lax service requirements.

To take an example, the server that runs the web server is an ancient single 
core machine (900MHZ, I think). But it still is 110 times faster than the 
8086 that I was using in the early days of Janus/Ada. (And the difference 
was probably greater than that, as that was a high-powered 16-bit machine 
[for the time, of course]; the server is 32-bit, of course). The tasking 
overhead is much less of a problem on such a machine (context switch times 
are a few microseconds rather than a few milliseconds), so one can use 
tasking productively. (And of course, our IBM PC/XT was about 3 times slower 
than the 8086 machine, which is what most people had.)

I had used bigger iron at the University of Wisconsin, (VAX 780s, for 
instance), but those had slowed to a crawl toward the end of semesters when 
everyone's projects were coming due. I doubt that they would have been happy 
doubling the overhead of running a program for the "benefit" of 
multitasking.

Surely tasking is useful *now*, and that's all that really matters. Ada was 
just a couple of decades ahead of its time.

                           Randy.