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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ce6f6f23c4e880ad X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-24 21:00:02 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!paloalto-snf1.gtei.net!crtntx1-snh1.gtei.net!lsanca1-snf1!news.gtei.net!enterprise!news.xtra.co.nz!53ab2750!not-for-mail From: "AG" Newsgroups: comp.lang.ada References: <3d123f34.0@news.unibw-muenchen.de> <3D128BA9.8090707@telepath.com> <3D16B14B.2A5D8261@attbi.com> <3D173788.8758A005@san.rr.com> <3D17E1E2.AED28873@san.rr.com> Subject: Re: Multitasking theory question X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: <5VRR8.145$7G4.15087@news.xtra.co.nz> Date: Tue, 25 Jun 2002 16:01:33 +1200 NNTP-Posting-Host: 210.54.67.222 X-Complaints-To: newsadmin@xtra.co.nz X-Trace: news.xtra.co.nz 1024977601 210.54.67.222 (Tue, 25 Jun 2002 16:00:01 NZST) NNTP-Posting-Date: Tue, 25 Jun 2002 16:00:01 NZST Organization: Xtra Xref: archiver1.google.com comp.lang.ada:26684 Date: 2002-06-25T16:01:33+12:00 List-Id: "Darren New" wrote in message news:3D17E1E2.AED28873@san.rr.com... > AG wrote: > > Well, let's take a step back and regard it as a theoretical question: > > If you use something like "inc ax" - how do you know if it's blocking > > or not? > > Um... It's not. I'm assuming the normal use of the word "blocking" here: > > "To delay or sit idle while waiting for something." > > You know an increment instruction isn't "blocking" because you're not > sitting idle during its execution. You know this because you read the > instruction manual for the CPU. Similarly, you know that the MS-DOS call to > wait for a key from the keyboard is indeed a blocking call, because of > similar types of documentation. Really? If I remember correctly, even the 3.something DOS could print while it waited for the key-press. Also, increment instruction can be blocking if it tries to access controlled memory (think optimistic locking for example). > > But surely this isn't what you were asking? > > > And how does it matter? Assuming the operation completes > > *at all*, > > Well, now, there's the rub, isn't it? How do you know it'll complete? If > it's waiting for the user, and the user is waiting for the other thread to > progress before typing, you just deadlocked. No, you are only deadlocked if there is a circular dependance. That is - the user must be waiting on a thread that is waiting on you. If that's the case - tough, no amount of scheduling would help (including OS). > Again, if you have two threads, and one calls an OS routine that loops > indefinitely, and the OS isn't supporting threads And suppose I call an OS routine that allows me to pull the cord from the plug but can't handle the results? Looping indefinetely isn't what I would call a reasonable behaviour. It is well-defined of course, but you might just as well have a "full-stop" as a result of any execution. > If the question is "where does the OS enter into it if I do all my > scheduling myself", the answer is "when you call the OS with one thread and > the OS prevents all the other threads from running." OK, I'll have to agree with that - if you really have an OS that can prevent you from executing arbitrary code regardless of permissions/access rightts etc etc that you have - then "no can do" I guess - the thing is simply broken. In fact, it's just not functional. > If you don't think this is an actual > concern, then you simply haven't tried to write multitasking programs under > a single-tasking OS. :-) Will a car-engine control program written under DOS on x86 machine qualify? :) It probably wasn't as hard real-time as some other things around but it certainly was heavily multi-tasking. And I hope you wouldn't call DOS non-single tasking.