Quote:
Originally Posted by
stevensw
Yea that might be the better way to do it. I guess I could write logic to check how busy a CPU is but that would be time consuming. I didn't know it doesn't try to run everything on the same core, but that's good knowledge.
And what would prevent your CPU busy-checking script making your CPU's busy? And how long would you expect one process to keep running on one CPU before it has to wait for something else? Should it sit idle while that process has to wait, or should another process run on it in the meantime?
What you are trying to write is an operating system, but you happen to already have one
Unless you have a real good reason to want a process on a specific CPU, you probably don't need to do so.
There
are good reasons, sometimes... Imagine you have two long-running, CPU intensive processes where the timing works out that, sometimes, they swap CPU's. A really intensive game on one processor perhaps, and Firefox in another. Switching processes from CPU to CPU wastes a bit of bandwidth sending cache bouncing around, causing both to lag. The OS, not being psychic, doesn't know they're destined to be long-running processes and may make less than ideal choices here. You, the user, know they're not quitting until you say so, so alter their CPU affinity masks to make sure they always execute on specific CPU's, reducing the lag.
Quote:
By the way how do you tell the OS to run a block of commands under the same background process such that there are multiple instances of these command blocks running in parallel?
I think you're confused on the definition of process -- if they're concurrent, and not threads, then by definition they're different processes -- so could you explain what you want in other terms?