>Thanks for that brief lesson, Ed.
>
>You describe a variation of what I was used to (and reasonably intimate with) on the mainframe IBM OSes. There a 'wait' had nothing "cooperative" about it - the operating system got control and preempted that task and dispatched another. In other words it was totally controlled by the OS and there was (virtually) nothing that a task could do to prevent this.

No, I didn't say that. Tasks can reset their priority to some extent on a temporary or permanent basis (take a look at SetPriorityClass, SetProcessPriorityBoost and procesing during idle loop in the Platform SDK and the Multithreading Overview topic for Visual C++ in the MSDN.) Cooperative multiprocessing is nothing more than a task voluntairly yielding the processor back to the dispatcher rather than having the operating system intervene because it has used up it's allocated resource. The OS is the dispatcher for the system - it determines who to grant time on which processor when it is given control.

There's considerably more to the multitasking and multiprocessing strategy of Windows than 'run until your time is up, and everyone gets an equal slice', or even an equitable slice. I really advise that you read the referenced material in Richter's book - I can suggest other books on the Win32 environment if you find Richter unpalatable.

The tasks request privileges and resources, but the resources are managed and granted to threads of execution by the operating system. Tasks don't directly decide what's going to run next, they do tell the operating system when they won't need time because they're waiting on something else to happen.

>Win seems to permit its 'tasks' to decide for themselves. Nothing wrong with that except, possibly, that one must be somewhat more intimate with each such 'task'.
>
>So I can now conclude that Dragan was indeed correct. Another piece of a huge puzzle is now in place.
>
>Thanks,
>
>Jim N
>
>>>I, too, was going to respond to Barbara similarly to yours, but then it occurred to me that the OS (Win in our case) has to be designed to handle such "wait states" appropriately. Personally, I have never heard of anything except timeslicing in relation to Win. This *could* mean that Win would simply continue to wait out the slice even in the (non)event of a wait state in the currently dispatched program. Do you happen to know more details (or even have some observations that suggest more smarts than this in Win)???
>>>
>>
>>While Win32 uses a 'timeslice' concept, a thread has the ability to release control back to the operating system pending an event - hardware or software; there's nothing preventing cooperative multitasking, and in fact, there are several APIs that allow a thread, fiber or process to release their allotted time until one or more event occurances are signalled (you might want to look at the assortment of WaitFor Win32 API calls to see the variety of ways that a thread can avoid needlessly burning cycles while waiting for something to happen.)
>>
>>A timesliced strategy to preemptive multitasking doesn't prevent the operating system from allowing or even encouraging cooperative multiprocessing. You might want to read Jeff Richter's Advanced Windows, chapters 2, 3 and 9 deal with process and thread strategies and thread synchronization, the first few pages of Chapter 10 on Windows messages have a very concise and descriptive summary of how multitasking and asynchronous events are handled (the majority of Chapter 10 deals with Windows Object messaging in general.
>>
>>>Cheers
>>>
>>>Jim N
>>>
>>>>>
>>>>>Any CPU can handle only one task at a time and must use time slicing to handle multiple tasks. IOW, it's not a VFP limitation, it's a CPU limitation. I have no first-hand experience with multiple processors, but have heard horror stories from those who have.
>>>>
>>>>Not necessarily. You may have a thread which does some disk/floppy/other HW operation, and these may use little processor time, so if it happens in a separate thread, the original thread may keep singing almost undisturbed. It doesn't have to wait for the HW issues to get done, so there's still some gain.