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?
>> 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 do know that historically Unix system seem to have an affinity for
splitting tasks by process and Windows moved towards threading; while in
the abstract they seemed similar and someone here will slap me with a
ruler (please do correct me) the big things that separate them include
shared memory addressing and how fine-grained the scheduling can be.
I remember reading in an interview with the qmail author (maybe I'm
misremembering, so someone would have to google if interested) that he
didn't redo a mail storage scheme because security and database
functions were becoming a kind of domain of filesystem writers and a
perfectly usable model was already done by people who spent their time
doing that work, so he essentially delegated that work to them by just
storing files on the filesystem. I thought in this situation it would be
applicable because for things like CPU scheduling, your app shouldn't be
necessarily aware, just let the OS handle it. You also don't know what's
in the works; I have apps that think they're running on dual processor
systems, when in reality they're in a VMWare session on dual multi-core
processor servers.
> Threading (and parallel processing) is something that a lot of people
> want to be able to do, but there are so many pitfalls that most people
> don't get it right.
Personally I think that is partially the fault of programming libraries
and languages; I also use that argument about security and buffer
overflows. Some programmers seem to wear a badge of honor that they use
<C/C++/assembler/favorite language> despite how difficult it can be to
use effectively and they have a self-inflicted hazing with every
application they write and this badge gives them the right to look down
on the new programmer coming into the field with a couple VB
applications in experience. A shame.
The language shouldn't make it difficult to catch all the gotcha's
(overflows, garbage collection, etc.) when the ramifications include
lost time and money because someone didn't include a specific destructor
or some other reference yet the @#$# thing compiles and seems to run fine.
But maybe that's just my opinion. I'm not a programmer by trade. :-)
-Bart
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|