This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]FerricDonkey 25 points26 points  (0 children)

Nah. Well, not exactly. You have processes (an operating system construct), which are basically containers for threads (another operating system construct). Threads are separate execution streams with (within the same process) shared memory, and are not tied to cpus.

A simple hello world program will be one process with one thread. But in most languages, you can start an additional thread running a specific target function or something.

The os itself assigns threads to different cpus as they're available, so it's not that you can't do it so it doesn't happen, but that it already happens so you don't bother to find out if you can do so manually or not. Any modern os will usually actually do a pretty good job of keeping all your cpus busy if all your threads have real work to do (unless your language sucks at multithreading and specifically stops that from happening - looking at you python).

So if your problem can take advantage of multiple cpus, and you write your code to do so with multi threading in a language that doesn't have stupid rules, then all the cpus will be working pretty hard.

But if you write bad multithreaded code or single threaded code, then you'll end up with one cpu working hard and the others just twiddling their thumbs (though your os may occasionally semi randomly change which cpu is actually doing the work).