Elizabeth D Rather wrote:
> Well, in the 70's and early 80's I worked on a lot of data
> processing-type programs on minicomputers supporting multiple (up to 64)
> users on dumb terminals. It was not an embedded system in the sense of
> being a control/data acquisition-type app, more of a database, but it
> was at least dedicated to running all somewhat-related Forth
> applications, not random programs in whatever language from whatever
> source.
I'm not sure what the point of your response is.
My message was about two broad classes of systems: Systems designed for
a specific purpose and systems that are general purpose. I used
"embedded systems" and "desktop/server systems" as two obvious examples
of each class. But I guess you wanted to point out the totally
unremarkable notion that there are blurry boundaries there.
Congratulations for stating the obvious.
You've described a system designed for a specific purpose-- running some
sort of multiuser database application. The fact that you aren't
sampling an A/D converter or driving a stepper motor doesn't take that
system out of the realm of what I was talking about. Using cooperative
multitasking on such a system also makes sense, again, because the
system has a dedicated function. And in that application, I'll bet that
you didn't have people doing things like *significant* software
development on the same system while it was running. Unless the
customer was okay with up to 64 users facing occasional downtime caused
by the odd typo, ! to hardware that shouldn't be touched, failure to
release the CPU, and assorted other human errors that happen during
development and testing.
For non-dedicated environments where a single machine will be used for a
variety of general purpose tasks, such downtime isn't usually
acceptable, and that is one thing that drives the need for preemptive
operating systems and things like protection mechanisms.
But let's get concrete. The message headers from you indicate you're
using some flavor of Windows to read this message. And if you're like
most Windows users, you enjoy the ability to pick and choose your
hardware and software. Maybe you use Office, but you could also choose
one of the many alternatives. Maybe you play MP3's in the background
while you're working-- and you have a lot of choices there as well, both
in media players and hardware to hear the music on. Maybe you sometimes
browse the web. Maybe you create presentations. Maybe you edit video.
Oh, and you probably write some Forth code too.
So there you are with your general-purpose PC sitting in front of you,
offering you the ability to choose hardware and software freely and move
between *wildly* different tasks that the hardware designers may not
have even predicted. I want you to tell me that you seriously believe
that a system built around the end user's *arbitrary* whims and *free*
choices in hardware and software (and language for software) could
effectively be managed with a purely cooperative multitasking system.
Please factor in a pragmatic appraisal of how people are in real life,
not some idealized "if everyone just follows the rules, everything will
be fine" naive optimism.
If your answer is yes, then you're unreasonable, or at least you're
willing to put up with a highly unreliable system. Most people aren't.
Most people don't want to have their desktop system go down (along
with all their other work) because a bug wasn't found during testing, or
because in some marginal case a task failed to yield cycles back to the CPU.
If your answer is no, then you've validated a major part of the reason
why preemptive multitasking operating systems exist-- for general
purpose computing where the end user is freely making choices and still
wants a reliable system.
Systems that are built for specific purposes... or that restrict
hardware choices... or that limit what software can run or what you're
allowed to do (such as no software development on a running system)...
or that say you must stick to a single language... the more areas in
which one can take a system and fix choices, the better cooperative
multitasking works.
Or put another way, it should be completely unsurprising to everyone
that a multiuser database system could be written in Forth using
cooperative multitasking techniques. What would be very surprising if
you believe that *same* system could be used to reliably do other
concurrent things based not on carefully designed and testing software
that was validated by system-level testing, but on the end user's whims
and choices. For example, what would be astounding would be if you told
me that you would have 63 users on that system all happily accessing the
database while at the same time one user who is learning Forth, sitting
an an ok prompt, freely writing routines that may block, trash state
because of accidentally swapped arguments to !, and other very human errors.
> Well, a lot of systems I've worked on have been in research environments
> where scientists will, indeed, bring in strange devices that we never
> heard of. And sometimes they wanted to write the software, too (with or
> without assistance).
And in these environments, it was probably understood that while Dr.
Smith is hooking up the XYZ2000 to the system and writing some routines
to access it, the rest of the system might come to a crashing halt, be
unresponsive, or do other unpredictable things. If you allow for the
system to be unreliable during such development and testing, then sure,
cooperative multitasking is perfectly fine. If this is unacceptable,
then Dr. Smith needs to do his development and testing when the rest of
the system isn't in use-- in other words, dedicate the system for a
specific purpose for a time.
> The essential thing in cooperative multitasking is the word,
> "cooperative". This means that whoever is writing code for it or
> plugging in devices must promise to follow the rules and play nice. You
> don't need to personally have 100%% control, if your colleagues will also
> assume responsibility.
It's not just about responsibility and "playing nice." Last time I
checked, humans make mistakes, even when they are sitting up straight
and following the rules. People forget. People get distracted. People
make assumptions that are false. People had too many carbs for lunch
and aren't thinking clearly. People screw up for an endless number of
reasons, not just because they are stupid or lazy, incompetent, or
irresponsible.
Testing can find most of this. But not all. Forth doesn't remove the
human element from programming. In fact, it amplifies it.
> In my world of cooperative multitasking, the rules are very simple: if
> you perform any I/O, you relinquish the CPU for as long as it takes for
> the I/O to complete. If you have a lengthy CPU-intensive operation
> (hairy math, big sort, etc.) you're responsible for briefly
> relinquishing the CPU at fairly frequent intervals. Providing everyone
> who writes code for this box will accept responsibility for following
> those rules, and test their code & devices reasonably, it'll work fine,
> whether the environment is a desktop or real-time funky hardware setup.
I like your caveat. It's kind of like saying, "if everyone who lived in
this city acted responsibly and always did the right thing, then we
wouldn't need laws, police, or a judicial system."
Again, a big problem here is choice. Let's assume the best-- that
everyone is responsible, follows the rules, and reasonably tests their
hardware and software. You used the word "reasonably". Tell me what
"reasonably" means when I can go to my local computer store and freely
choose from at least 25 different motherboards, maybe a dozen different
CPUs, endless memory configurations, videocards that range from simple
frame buffers to high-end graphics accelerators, sound devices that
range from monophonic to eight speakers, and endless combinations of
peripherals. And I haven't even gotten to the software yet and the
nearly infinite ways I can pick and choose and configure code.
What does "reasonable" mean in that kind of environment? Without
resorting to wild arm waving, explain to me how such an environment
could *practically* work with cooperative multitasking and a lack of
protection mechanisms. What would be the method end users would use to
ensure that their arbitrary and free choices were "reasonably" tested?
Is it a stamp on the box from a certification lab? Is it the company
proudly flying some kind of banner that says they're now ISO-9000 (or
whatever) compliant?
That's a big problem here in comp.lang.forth-- people will issue
statements like "if everyone just tested better and followed the rules"
and pretend that the underlying human issues simply go away. Yet I'm
willing to bet that if the general public had access to Forth, Inc.'s
internal bug reporting system we would find a non-zero number of bugs in
released software. Gosh, how did that happen? Were your staff not
testing and playing by the rules?
> It's actually pretty hard for most programs to do much without some
> kind of I/O: reading/writing disk, screen, playing music, whatever.
And it's pretty easy for even the best people to make mistakes.
What I really hate about this thread is the not-so-hidden statement that
the choice of cooperative multitasking verses preemptive multitasking is
a choice between responsibility and irresponsibility; between diligence
and laziness; between design and chaos. Why can't it be seen as a
choice between optimism and pragmatism? Why can't it be seen as a
choice between attacking the problem of reliable systems from two
different perspectives, each with advantages and disadvantages? Why
can't the issues here be discussed without arm waving and ignoring human
psychology?
