Windows C++ Process vs Thread

Question

In Windows C++, createThread() causes some of the threads to slow down if one thread is doing a very CPU intensive operation. Will createProcess() alleviate this? If so, does createProcess() imply the code must reside in a second executable, or can this all take place inside the same executable?

Create the new thread with a lower priority then the existing threads. But then the new thread won't be able to perform it's task at full speed since he will have to release the CPU to the other two threads. — RedX, Apr 15 '11 at 13:45
"*In windows c++, createThread() causes some of the threads to slow down if one thread is doing a very CPU intensive operation*" Where did you get this impression? — ildjarn, Apr 15 '11 at 13:46
I see it happening. I have two threads running. When thread A runs a very intensive algorithm, thread B is slows down substantially. — rossb83, Apr 15 '11 at 13:49
You should do some profiling using windows Performance Monitor to see if both threads really are using close to 100% CPU in this scenario. — Justin Ethier, Apr 15 '11 at 13:55
@rossb83: That's generally caused by a lack of processor resources, not the Windows API. `CreateProcess` won't buy you a faster CPU. — MSalters, Apr 15 '11 at 13:57
This seems like a followup to your previous question: http://stackoverflow.com/questions/5651170/c-multi-thread-execution-speed-slow-down Something still doesn't add up. With 4 cores (as I presume you still have) you most likely have some other issue than the CPU bound calculation. It is likely something in the way you are processing. — edA-qa mort-ora-y, Apr 15 '11 at 14:07
Well what I didn't tell you guys was this was a test. I purposely made one of the threads work extra extra hard. I wanted to see if there was a good way to balance resources. — rossb83, Apr 20 '11 at 18:09
This question, and seemingly it's answers as well, seem to miss the point that any "cpu intensive task" will slow down other tasks. This isn't a thread vs process issue, but the fact that each core can only execute so many instructions per second. Context switching adds to these instructions and can also bring other issues that basically come down to the throughput of involved components - the process of moving this data around isn't magical or free - but the actual effect is a matter of proportion. — JSON, Jul 12 '23 at 17:55

score 9 · Accepted Answer · answered Apr 15 '11 at 13:44

9

The major difference between a process and a thread is that each process has its own memory space, while threads share the memory space of the process that they are running within.

If a thread is truly CPU bound, it will only slow another thread if they are both executing on the same processor core. createProcess will not alleviate this since a process would still have the same issue.

Also, what kind of machine are you running this on? Does it have more than one core?

answered Apr 15 '11 at 13:44

Justin Ethier

131,333
52
229
284

1

If you really think your process is CPU bound, you could try to set the affinity of each thread: http://stackoverflow.com/questions/3366932/identify-processor-core-is-used-by-specific-thread But since this is a 4 core system, it seems likely there is something else slowing things down. Do you think there might be contention between the threads for some kind of shared resource? For example, are threads being blocked while waiting to access a shared data structure? – Justin Ethier Apr 15 '11 at 13:53
Justin interesting comment. The answer to this comment, is I didn't think so, but maybe so. Yes there is a large array buffer I have, 100 MB in size declared A = new char[100*1024*1024]. I have thread A writing to the beginning of this buffer, say the first 10 MB, while thread B reads from another position in the buffer say the last 10 MB to do the intensive processing. Although it is declared as the same array, both threads are reading and writing to different parts of the array. Is this still a shared resource? – rossb83 Apr 15 '11 at 14:02
This assumes that that all threads have equal priority in the task scheduler, regardless of what process holds them. Is this true in Windows? I might have thought that a threads in a separate process had more priority then additional threads in a process that's already hogging the CPU resources. – ThomasMcLeod Apr 15 '11 at 14:08
@rossb83, technically no, not a shared resource. In any case, there would only be contention if you were using synchronization. http://msdn.microsoft.com/en-us/library/ms686353(VS.85).aspx – ThomasMcLeod Apr 15 '11 at 14:11
1

Right, if you are not synchronizing then one thread should not affect another. I still think there is something else going on here, though. I suggest you try to profile the application to try and understand what is going on at runtime. You could try to post code here if you have a small example, although that may be asking too much if you already have a large code base you are working with... – Justin Ethier Apr 15 '11 at 14:39

score 1 · Answer 2 · answered Apr 15 '11 at 13:50

Not likely - a process is much "heavier" than a thread, so it is likely to be slower still. I'm not sure what you're asking about the 2nd executable, but you can use createProcess on the same .exe.

http://msdn.microsoft.com/en-us/library/ms682425(v=vs.85).aspx

It sounds like you're chasing down some performance issues, so perhaps trying out a threading-oriented profiler would be helpful: http://software.intel.com/en-us/articles/using-intel-thread-profiler-for-win32-threads-philosophy-and-theory/

score 1 · Answer 3 · answered Dec 30 '11 at 02:21

Each process provides the resources needed to execute a program. A process has a virtual address space, executable code, open handles to system objects, a security context, a unique process identifier, environment variables, a priority class, minimum and maximum working set sizes, and at least one thread of execution. Each process is started with a single thread, often called the primary thread, but can create additional threads from any of its threads.

A thread is the entity within a process that can be scheduled for execution. All threads of a process share its virtual address space and system resources. In addition, each thread maintains exception handlers, a scheduling priority, thread local storage, a unique thread identifier, and a set of structures the system will use to save the thread context until it is scheduled. The thread context includes the thread's set of machine registers, the kernel stack, a thread environment block, and a user stack in the address space of the thread's process. Threads can also have their own security context, which can be used for impersonating clients.

score 0 · Answer 4 · edited Jun 20 '20 at 09:12

Create process and create thread both cause additional execution on what is a resource limited environment. Meaning no matter how you do parallel processing at some point in time your other lines of execution will imped the current. It is for this reason for very large problems that are suited to parallization distributed system are used. There are pluses and minuses tho threads and processes.

Threads

Threads allow separate execution inside of one address space meaning you can share data variables instances of objects very easily, however it also means you run into many more synchronization issues. These are painfull and as you can see from the shear number of api function involved not a light subject. Threads are a lighter weight on windows then process and as such spin up and down faster and use less resources to maintain. Threads also suffer in that one thread can cause the entire process to fail.

Processes

Process each have there own address space and as such protect themselves from being brought down by another process, but lack the ability to easily communicate. Any communication will necessarily involve some type of IPC ( Pipes, TCP , ...).

The code does not have to be in a second executable just two instances need to run.

MSalters · Answer 5 · 2011-04-15T14:13:27.593

That would make things worse. When switching threads, the CPU needs to swap out only a few registers. Since all threads of a process share the same memory, there's no need to flush the cache. But when switching betweeen processes, you also switch mapped memory. Therefore, the CPU has to flush the L1 cache. That's painful.

(L2 cache is physically mapped, i.e. uses hardware addresses. Those don't change, of course.)

Windows C++ Process vs Thread

5 Answers5