4
$\begingroup$

I understand context switches and threading on a single core system, but I'm trying to understand what happens in a multi-core system. I know multiple threads from the same process can run simultaneously in a multi-core system. However, can multiple processes run simultaneously in such a system as well?

In other words, in a dual core processor: - How many processes can run simultaneously(without context switching) if all processes are single threaded? - How many processes can run simultaneously if there are 2 processes and both are multi-threaded?

$\endgroup$
  • 4
    $\begingroup$ While this seems to be a good and reasonable question, I'd like to encourage you to try to answer this empirically for yourself. Do you have a multicore system? If so, fire up a bunch of compute-intensive programs (maybe write some yourself?) and check the activity of processor cores to deduce whether some program instances are running truly simultaneously. $\endgroup$ – Patrick87 Aug 19 '14 at 16:24
  • $\begingroup$ @Patrick87, thanks for the suggestion. I did think about that, but I don't have any control over the scheduler and I can't really kill off all but 2 processes of my choosing, so I couldn't figure out how I could do this experimentally. Any ideas? Edit: I forgot to mention that the issue I had thought about was that I wouldn't be able to distinguish between multiple processes running simultaneously vs being context-switched. $\endgroup$ – Tachy Aug 19 '14 at 16:57
  • 1
    $\begingroup$ I don't think that this is a computer science question. The answer is ultimately up to the specific operating system (and maybe the hardware) you use, neither of which are within our scope. $\endgroup$ – Raphael Aug 19 '14 at 17:17
  • $\begingroup$ @TriArc: Most computers are idle most of the time. The few extra processes that are running here and there won't matter. Just write a single threaded program that does something compute intensive (like summing up all the 64-bit integers integers between 1 and 2^36 (mod 2^64) and printing the answer.) Run 1 copy of the program. How long does it take to finish? Run 2 copies of the program simultaneously. How long does it take? Now run 3 and 4 copies. If you see that 2 copies take about the same amount of time as 1 copy, but 4 copies take twice as long, what does that tell you? $\endgroup$ – Wandering Logic Aug 19 '14 at 17:47
  • 1
    $\begingroup$ @TriArc Wandering Logic gives the core of the idea. Basically, try running one, two, ..., instances of your program simultaneously, and measure the results (how long the programs take to finish, the system load, etc.) Based on this data, deduce whether the results are consistent with running one process at a time, or consistent with running as many processes simultaneously as there are processing cores. It's true that some of the system load will be due to programs not under your control, but with a bit of effort you can get the CPU usage pretty low. $\endgroup$ – Patrick87 Aug 19 '14 at 18:48
2
$\begingroup$

Yes multiple processes can run simultaneously (without context-switching) in multi-core processors.

If all processes are single threaded as you ask then 2 processes can run simultaneously in a dual core processor.

The same for multi-threaded processes as you ask, 2 processes again, one for each core could run at the same time.

You can verify the above by using the command line 'top' in linux systems or the 'Task Manager' in Windows. Launch two CPU-intensive processes for a dual core processor and see how they get close to 100% for each cpu core and a third process gets in the way of that 100%. For a quad core the same occurs with 4 processes and the fifth and so on.

Do not confuse multi-core with multi-thread support. 1 core may be able to run just 1 or more threads (if it is single-threaded core or multi-threaded core respectively). For example, AMD FX 8350 has 8 cores each able to run a single thread of a process while Intel i7 3770K for example has 4 cores each able to two threads of a process. But somewhere here we are getting beyond what you asked so I hope this covers it!

| cite | improve this answer | |
$\endgroup$
0
$\begingroup$

This question is more related to the difference between a thread and a process. Here is a hint: When it comes to kernel scheduling structures, the only thing the kernel looks at is threads, not processes.

A process is easier to understand as a group of threads. All processes have to have at least one thread, and it is that thread that is scheduled in the operating system, not the process.

So, with this understanding, in a dual core system with two processes each containing a thread each, there are two threads total that are scheduled on the two cores.

| cite | improve this answer | |
$\endgroup$
  • 1
    $\begingroup$ The question is a little more interesting than that. There are resources (e.g. page table) that are always shared by two threads in the same process but may not be shared by two different processes. What assumptions are you correctly (but implicitly) making about those resources? $\endgroup$ – Wandering Logic Aug 19 '14 at 19:13
  • $\begingroup$ Your'e right, but I think a better understanding here is that threading is a resource of a process. A thread is basically a way in which compute units are allocated to a process. The process has a set of resources: threads, page table layout, file descriptors, etc. That two or more threads in the same process access the same other local resources is interesting but only tangentially relevant to the scheduling question. $\endgroup$ – Dougvj Aug 20 '14 at 3:39
  • 1
    $\begingroup$ But it is very relevant that each core supports an independent page table. If there were only one page table shared by all the cores (as is the case in many GPUs, for example) then you would not be able to schedule threads from different processes simultaneously. $\endgroup$ – Wandering Logic Aug 20 '14 at 11:17
  • $\begingroup$ You are of course correct. Threads are very different in such hardware as GPUs, custom FPGA solutions, and other SIMD-type solutions. At that point a thread refers more to data-level parallelism than you are to concurrency, since not only does each share the same "page table" (TLBs aren't used in GPUs AFAIK) but also they share many execution resources such as instruction decoding as well. I assume that the OP's question referrs to SMP because in that sense such terms as "single-core", "multi-core" and "simultaneous processes" make the most sense. Perhaps that's a bad assumption. $\endgroup$ – Dougvj Aug 20 '14 at 16:03
0
$\begingroup$

Define "run".

As I am typing this, my MacBook has about 150 processes running, with a total of maybe 800 threads (rough guess checking Activity Monitor).

Since this MacBook has two cores without hyperthreading, at any given time two threads and no more can be executing (actually using the CPU). Any number of threads could be ready for execution (that is they would be running apart from the fact that both cores are already busy), if there are threads ready to run but not running, the OS will from time to time pause on of the two running threads and let one of the other ready threads run. But of the 800 threads, most are not ready, but are waiting for something (like waiting for work to appear that they can perform).

There is no restriction to the number of different processes that running threads and ready threads could belong to.

There will be some limitation to the number of processes and threads, but that limitation will be somewhere in the thousands, and hugely bigger than the number of threads that can be executing.

| cite | improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.