Re: ADA os talk

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:3CeB8M0VaOC6@eisner.encompasserve.org...
>
> I don't suppose this "study" time was billed by the hour ?
> Of course it is possible the documentation was worse during
> the time period you are discussion.
>
We had VMS guys who had to build up lots of experience with OS calls, etc,
to get the job done. You didn't just walk in out of college knowing it. They
were quite disappointed when we were forced to switch to some flavor of
(realtime) Unix because it meant having to start all over again developing
job skills. Maybe the skills were a bit more marketable by then, so I guess
it was O.K. Billing it? I think they were mostly overhead - not direct
charging to contracts. But it is legitimate to bill the time needed to
familiarize with tools, etc, if it is for a specific need on a contract.

Like I said, my memory of the situation whas that techniques were possible
under VMS to run realtime, but that VMS wasn't designed to specifically
provide some kind of realtime mode. Sort of a case where if you had enough
privileges and enough priority and could keep anything else from taking
precidence, you could convince yourself that you had fixed latency and
weren't going to get swapped out. This is different than having a process
that the OS manages in realtime mode and guarantees you that none of this is
going to fail.

> > What would be nice is to have a workstation OS that didn't require you
to
> > become an expert or circumvent the OS to do realtime - just declare a
> > process to be "realtime" and know that it can get certain services with
> > certain predictable latencies and be sure that it has priority over
anything
> > else. (Dangerous, but necessary for realtime programming.)
>
> Based on the real-time people I have met, I would say that each
> shop is still going to study the situation to ensure they
> are not making inwarranted assumptions.

Well, naturally, you don't just walk in, sit down and start programming real
time systems on an OS you've never seen before. You've got to know what the
OS is doing for you and how it does it. I'm talking about a difference
between "Here's the book on how a realtime process runs on ImaginaryOS..."
versus "Here's a bunch of system calls and descriptions of what's going on
in the OS and you go figure out some tricks that are going to let you run
realtime because we didn't build in a 'realtime' mode of operation..." The
latter case can definitely be done, but it usually is going to involve more
time and effort.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/