I wrote a single-thread program using codeblocks but in task manager it shows that the program is using 2 threads?

Question

I wrote a program in codeblocks and the code is shown below.

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char* argv[])
{
    int Param, i, j, k;
    if(argc != 2){
        fprintf(stderr, "An integer parameter is required \n");
        return -1;
    }
    Param = atoi(argv[1]);
    if(Param<0){
        fprintf(stderr, "An integer >= 0 is required \n");
    }

    printf("first \n");
    for(i = 0; i < 1500; i++)
        for(j = 0; j < 1500; j++)
            for(k = 0; k < 1500; k++);

    printf("second \n");
    for(i = 0; i < 1500; i++)
        for(j = 0; j < 1500; j++)
            for(k = 0; k < 1500; k++);
    printf("Done \n");

    return 0;
}

In the program, I didn't use any multithread function and libraries like windows.h or thread.h. But when I opened the task manager to observe the threads it used, I was surprised that the program was using 2 threads. I have no idea why this can happen. Is there something added into the program I wrote while compiler is compiling my program? Please help me to find out the mystery.

This is the picture about the question.

You seem to have multiple `single-thread.exe` programs, some which seems to create threads (despite the name of the executable program). Are you sure it's not one of them that are still running? — Some programmer dude, Mar 20 '19 at 08:52
I only have this program called single-thread.exe and I am sure that only one program call single-thread.exe runnung in the same time. — Sun Hao Lun, Mar 20 '19 at 08:58
If I use visualstudio , the threads will become 4 threads. It is strange. — Sun Hao Lun, Mar 20 '19 at 08:59
When you run a debug build, there may be much more going on than just the code you've written. For instance, the program may be communicating with you IDE in order to help you with debugging (so you can examine values, see where it crashed, and so on). Those things may run in their own thread(s) and make up most of the memory usage of small programs. Don't worry about it. — Blaze, Mar 20 '19 at 09:12
You are using Win10, befitting a modern OS it does take advantage of your machine having multiple processor cores. They get your program started faster. Details [are here](https://stackoverflow.com/a/34826385/17034). — Hans Passant, Mar 20 '19 at 09:27
Did you build for release? If a debugger is attached, it will have to read the process memory somehow, like for example through a separate thread. — Lundin, Mar 20 '19 at 09:34
@Lundin - this not related to debugging. and debuggers not create separate thread in target process for read it memory (no sense). this is os created working threads — RbMm, Mar 20 '19 at 09:46
@RbMm Some tool chains put the whole debugged program inside it's own memory. What it does internally is anyone's guess. Various dynamic analysers does inject something inside the target process. Quite hard to discuss this without a specific tool chain in mind. — Lundin, Mar 20 '19 at 09:50
@Lundin - yes, of course some program, can inject remote thread in target process, but here i sure we have os created worked thread(s). easy can view this if use debugger — RbMm, Mar 20 '19 at 09:59
There are system-managed threads as well. For example, the system has a thread to handle what happens if the user types Ctrl+C to terminate your application. — Raymond Chen, Mar 20 '19 at 14:04

pr0f3ss · Answer 1 · 2019-03-29T22:35:37.237

1

This might be a case of implicit parallelism where your CPU/compiler will exploit instruction level parallelism (ILP for short) to improve sequential processor performance. As your two for loops are independant of each other your compiler will make use of vectorization and your processor will automatically create threads to shorten execution time. Therefore you are running 2 or even 4 threads, dependant on your compiler/system.

edited Mar 29 '19 at 22:35

answered Mar 20 '19 at 09:16

pr0f3ss

527
1
4
17

2

Why would a compiler do that unbidden and automatically? I very much doubt it. Especially since executing this code in multiple threads would be less effective than a single thread due to thread creation overhead. Pipelining has nothing to do with threads and is handled by the CPU. – Lundin Mar 20 '19 at 09:36
There's something about the words "instruction level" than make me think that ILP happens at the level of instructions and does NOT happen as "multiple threads (of instructions)". – Brendan Mar 20 '19 at 09:38
3

no. this is os created working threads. nothing related to compiler – RbMm Mar 20 '19 at 09:50
1

@Brendan ILP allows to overlap (i.e. parallelize => use of multiple threads) the instructions and even reorder the instructions executed. – pr0f3ss Mar 20 '19 at 10:07
@RbMm ILP is also implemented on processor level, meaning it can create threads on OS level. – pr0f3ss Mar 20 '19 at 10:14
@Lundin Certain compilers and/or processors will make greater use of ILP than others. A 3 nested for loop twice is expensive and therefore the thread overhead is not comparable to the execution time, leading to the compiler and/or professor making the decision to parallelize the instructions. – pr0f3ss Mar 20 '19 at 10:21
no, 100% nothing related to this. op must look for this thread start address and look under debugger. and will be visible – RbMm Mar 20 '19 at 10:21

I wrote a single-thread program using codeblocks but in task manager it shows that the program is using 2 threads?

1 Answers1