From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: IBM Funny
Date: 12 Oct 92 16:58:51 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <1992Oct10.101146.17789@netcom.com>, jazz@netcom.com (David C. Navas) writes:
> In article <6171.2ad5a59b@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:
>>No, it isn't that preemptive tasking helps, it is just that there are many
>>more examples of passable preemptive tasking systems than non-preemptive 
>>ones.
> 
> Giggle.  Oh, you have to love this one.  :)

What's funny? I believe the statement is true.

> I disagree with you Bill.  Preemptive multitasking helps because it takes
> the burden from the programmer's shoulder and puts it on the system's.

There's some credence to that. But that doesn't mean there's only one
way to do it. Indeed, I have a friend who is a Doctorial candidate at
Ga Tech. He's got at interesting thesis topic that could do away with
preemptive multitasking as a low-level primitive. (You would instead install
it at a higher level) Following his thesis, you could just as easily make
a non-preemptive system that runs in the same way: taking the burden from
the programmer's shoulder.

> This is an evolution (as anyone from Taligent is likely to point out) of
> system design.  The Mac took many of the burdens from the user and placed
> them on the programmer.  Preemptive multitasking (and MANY other things)
> takes the burden off of the programmer and places it on the system.

This may be true for applications. I believe it falls short when you suggest
that we move preemptive multitasking into the application. (Multithreading)

Doing so is a trade off. You trade off concurrancy for simplicity in coding.
In a single threaded application, you can easily predict what is going to
happen, since your code has control. In a multithreaded application, your
code could be usurped at any time, and some other code could steal away
data structures and other resources without your knowledge. The result
is that you have to very carefully protect common data structures.

I don't feel that multithreading makes anything easier. You merely trade off
one problem for another. Depending on your application, this could be a good,
or a bad trade.

>>I disagree. I don't see how it [multi-threading] makes this [multiple
>>documents] any easier.
> 
> It allows you an easy way of eliminating modality.  This is not the only
> tool that allows you this, though.

I don't see how multi-threading eliminates modality.

> 
>>Indeed, based on my experience, I can see how it would actually make things
>>more complicated. When you unleash concurrancy in an application, you have
>>to fight to keep your common data structures protected. If your junior
> 
> Your junior programmer should be developing in a concurrent-aware programming
> language, then....

The problem isn't limited to junior programmers, BTW.

Yes, it would help.

However, look at those OSs that offer multithreading? Are they programmed
exclusively in a concurrant-aware PL? No. They are using C. 

> Or at the very least, you should have an OO setup where your common structures
> have method-access that has already been written with concurrency in mind.

Are these offered exclusively in those OSs that offer multithreading? No.
Do they even exist for something like, say, OS/2? No.

> Either way, you're constraining your views on the subject by constraining
> the tools you have available to work with.

It is hard to use tools that aren't available.

Of course, my views are formed around my experience, and my experienced 
comes from what I've had to work with. That's pretty much true of everyone.

>>programmer misses just ONE of those spots -- WHAMMO -- you've got a nasty
>>bug that may take you weeks to fix.
> 
> Yes, that -is- true.  That's true of -any- memory trashing bug, of which
> non-semaphored access to shared structures is just one example.

And the worst part is that it could happen ANYWHERE. That's the tradeoff.

>>I'll keep as much multithreading out of my applications as I can. Thank you.
> 
> To each his own.

C'est la Vie.

>>OK. Just don't say I didn't warn you....
> 
> Bill, I have no problem writing this type of app, and I'd hardly call myself
> any kind of programming guru.

Well, I'd call myself a programming guru, and I'm hesitant to take on
another such assignment, again. <grin>

-- 
Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
Disclaimer: "My employer doesn't pay me to have opinions."
Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.

Newsgroups: comp.sys.mac.advocacy