On May 30, 2008, at 10:26 AM, Bart Silverstrim wrote:
> Glenn L. Austin wrote:
>
>>> Could you elaborate on this? I thought all NT lineage was
>>> preemptively
>>> multitasking, with a Win16 compatibility system for older
>>> applications
>>> that was cooperatively multitasked within itself...?
>>
>> But the NT scheduler (through XP) absolutely sucked in terms of
>> permitting a single process to "starve" other processes. That has
>> been improved with Vista.
>
> Is there a reference somewhere where I can read about this? I wasn't
> aware of this issue routinely occurring...I thought this was an issue
> with cooperative multitasking (at the system level) unless it was a
> resource contention issue, and there was a dynamic mechanism built
> into
> the NT scheduler to boost priority of processes to prevent
> starvation...anything maybe Ballman or Russinovich or something of
> that
> style talking about the issue you're referring to?
It was easy to demonstrate -- just start a processor-consuming process
and try to do anything else.
However, that was not the worst problem with Windows scheduler and
synchronization primitives, just the most obvious.
>>> You're saying design your app to be multiprocess and not
>>> multithreaded?
>>
>>
>> Design it to be multi-processor-aware, and you're far better off than
>> multi-threaded. When you start thinking "multiple processors" you
>> start thinking about contention for resources (multiple processors
>> attempting to access the same resource) and parallelizing your tasks
>> by reducing "sync points" between multiple processes.
>
> I'm honestly not arguing, only trying to further my understanding;
> isn't
> the multiprocessor scheduling or awareness soemthing that should be
> abstracted away from the programmer, something the OS handles? I would
> have thought that was especially true of something like RB where your
> functions must be handled by different OS's and when it comes to
> something like Linux, that platform couldn't (still can't?) agree on a
> library for handling threading safely.
I wish that it were that simple. Multiprocessing (and parallel
processing) are a completely different mindset -- so different in fact
that it is difficult to "prove" a multiprocessing system.
Let me try to explain it using an analogy. Say that you're delivering
three parts of a physical product, and you have three different
vehicles: an off-road motorcycle that has no vehicle license, a 4x4
pickup, and a sports car. No vehicle can carry more than one part,
and the vehicles can't travel the same route, but the destination is
accessible to all three. In their own elements, they take equal times
to traverse their routes. The motorcycle can go on trails that are
very direct but can't go on roads. The 4x4 can't go on the direct
trails, but can take a slightly longer route over rough gravel roads.
The sports car can only travel on paved roads, which is the longest
route.
All three vehicles leave at the same time, and *should* arrive at the
same time, but because of delays on each route, they may not arrive at
the same time. Each vehicle is totally independent of the others, but
are capable of delivering their part. Each vehicle is dependent upon
its route, but each route may have its own delays that are
unpredictable and are different for each trip.
Now, predict when all three vehicles will arrive at the destination,
and which order. Prove that they will always arrive in that order, or
that you can predict when they will arrive.
--
Glenn L. Austin <><
Computer Wizard and Race Car Driver
<glenn at austin-home dot com>
<http://www.austin-home.com/glenn/>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|