Think about Loose Coupling | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
another point that seems troublesome, is that can you be sure that the thread spawned will go into another core?.... for instance.... to use tirwhan's 1-liner as an example..... he says as you spawn multiple threads, they automatically get assigned to other cores..... but what if one core is already heavily loaded?..... wouldn't the scheduler tend to drop more than one thread into one of the unloaded cores?. You don't assign threads to cores, the scheduler does. Essentially, when you create a thread (at the C/machine-code level), you are simply adding a node (a struct) to a kernel-internal list, queue or tree. The kernel gets woken up by a hardware interrupt every few milliseconds and it decides if the current thread has had its time slice. If it has, it saves the contents of the CPU registers (into the node that was added when the thread was created), and picks another thread from those in the list (or queue or tree). The algorithm used to decide which thread is next varies from OS to OS; and kernel to kernel (and kernel version to kernel version). In an SMP (multi-core or multi-cpu) system, each cpu picks from the same list. So there is no determinism about which cpu will run any given thread, it is just down to which one pops out of the scheduling algorithm of choice. ...i do wonder about the wisdom of allowing a process to launch threads into other cores, other than the one it's parent exists in..... Don't concern yourself. Processes are not assigned to cores--threads are. A process consists of a (protected, in modern OSs--including *nix and MSWin :), virtual address space + one (or more), threads. Virtual address spaces (on Intel, but equivalently on other modern processors), are controlled by ring 0 entities called Global Descriptor Tables (GDTs). Threads are bound to one (or a few) GDTs, and have no ability to change those bindings. In other words, processes, and therefore, the thread(s) of those processes, are protected from each other, by hard-wired (hardware) protection mechanisms. Whilst it is possible (under MSWin, given sufficient privilege; and probably under *nix, but I don't know enough to say for sure), to "inject a thread into a different process", it does require privilege. If you habitually run as root (Administrator), this can render you vulnerable. The solution: Don't! For the pedants: Of course, this is a gross simplification and not truly representative of any given system. But the devil is in the detail. Namely, the "scheduling algorithm of choice". Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
In reply to Re^8: Standard way to convert timezone in multithreaded script
by BrowserUk
|
|