Unix process is endless

I am wondering what is going on in a program that only has while(1);

a function main()

when compiled with g ++ on unix. When I run the program, I see 0% CPU usage. Why is this? Shouldn't that be processor dependent?

Does the compiler optimize this? By placing a method like the yield_processor syscall does this context get disabled?

Code compiled with g ++ using default optimizations (just compiled as g++ source.cpp

)

int main()
{
  while(1);
}

      

Thank!

+2


source to share


3 answers


Since no dependencies are displayed in the body while (), gcc creates an empty trigger for this piece of code. Now, depending on the standard flags you are actually using (also check the env. CFLAGS and CXXFLAGS variables if in a * nix environment), the compiler does not generate asm "hogging" code.

Just check after executing g++ -S source.cpp

the source.s file (containing the ASM code) if the loop was created or not.

Here's my output without g ++ optimization flags (GCC) 4.5.0 20090910 (experimental):



    .text
.globl _main
_main:
LFB0:
    pushq   %rbp
LCFI0:
    movq    %rsp, %rbp
LCFI1:
L2:
    jmp L2
LFE0:
    .section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
EH_frame1:
    .set L$set$0,LECIE1-LSCIE1
    .long L$set$0
LSCIE1:
    .long   0x0
    .byte   0x1
    .ascii "zPR\0"
    .byte   0x1
    .byte   0x78
    .byte   0x10
    .byte   0x6
    .byte   0x9b
    .long   ___gxx_personality_v0+4@GOTPCREL
    .byte   0x10
    .byte   0xc
    .byte   0x7
    .byte   0x8
    .byte   0x90
    .byte   0x1
    .align 3
LECIE1:
.globl _main.eh
_main.eh:
LSFDE1:
    .set L$set$1,LEFDE1-LASFDE1
    .long L$set$1
LASFDE1:
    .long   LASFDE1-EH_frame1
    .quad   LFB0-.
    .set L$set$2,LFE0-LFB0
    .quad L$set$2
    .byte   0x0
    .byte   0x4
    .set L$set$3,LCFI0-LFB0
    .long L$set$3
    .byte   0xe
    .byte   0x10
    .byte   0x86
    .byte   0x2
    .byte   0x4
    .set L$set$4,LCFI1-LCFI0
    .long L$set$4
    .byte   0xd
    .byte   0x6
    .align 3
LEFDE1:
    .constructor
    .destructor
    .align 1
    .subsections_via_symbols

      

This code supports my processor as expected (on Mac OSX 10.6.1).

+1


source


You either have a bug in your code, too much optimization (unlikely), or misuse of your processor.



Either way, you're right. He must "raise the processor".

0


source


It is not strictly against the rules for your compiler to do something smart with this code. By the "as if" rule, there is no way for your program to tell if it is actually looping or just sleeping.

I would like to know more about which version of GCC you are using and which OS. GCC-4 on Mac OS X does nothing special with this code.

Of course, your OS may have a limit set for CPU usage by one process. I think that in this case the process will stop.

0


source







All Articles