1

How do I start a new thread in parallel without pausing the main function?

Here is my code:

void someFunction { while(1);}

int main(){

thead *th = new thead(&someFunction);
thead.join();
return 0;

}

But program doesn't stop


P.S. How run thread in parallel source

Omnifarious
  • 54,333
  • 19
  • 131
  • 194
Serge Yudin
  • 138
  • 7
  • `join()` waits for the thread to finish and is blocking it's already started after you created the thread. But you should call join() in the main thread before you exit or terminate it. – PeterT Jan 18 '12 at 18:22

5 Answers5

4

In C++11, the implementation is permitted to assume that this kind of loop terminates. So your code can be optimized to nothing at all. Otherwise, lots of legitimate and valuable optimizations wouldn't be possible, but the effects can occasionally be surprising.

Community
  • 1
  • 1
David Schwartz
  • 179,497
  • 17
  • 214
  • 278
3

The program can't stop as the main thread calls thread.join() which means that it will wait for the thread "thread" to finish, however that one is calling a function which never finish as it loops to infinity.

Stephan Dollberg
  • 32,985
  • 16
  • 81
  • 107
2

Your thread.join(); is waiting for the secondary thread to exit, but since the secondary thread is executing an infinite loop, it'll never exit.

Edit: I should add that the standard gives enough leeway to allow the thread to exit, but it's not required.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
  • Creating a thread object (`new thread(someFunction);`) creates the new thread of execution running the function you specified. – Jerry Coffin Jan 18 '12 at 18:29
1

You joined to a while(1) loop. The program will stop when the while(1) ends, ie. never.

Martin James
  • 24,453
  • 3
  • 36
  • 60
  • Or immediately. This is C++11, "A loop ... may be assumed by the implementation to terminate." – David Schwartz Jan 18 '12 at 18:31
  • @DavidSchwartz - presumably then, the join results in a reference to the loop that prevents the compiler optimizing it away? – Martin James Jan 18 '12 at 19:21
  • Not likely. There's no reason one would have anything to do with the other. If the code terminates, it's either because the compiler was not smart enough to optimize out the loop or was smart enough to figure non-termination was intended. (If I were writing a C++11 compiler, I wouldn't optimize out a loop that was obviously intended to never terminate because it's surprising behavior. I'd use the rule only if I couldn't tell if a loop terminated or not but could tell it had no other effects.) – David Schwartz Jan 18 '12 at 19:50
  • Does the standard actually say that anymore, @David? I thought that part was removed in N3225. N3291 says (in 1.10/24) that an implementation may assume various things about a thread, one of the options being that it will terminate, but it doesn't say the implementation may assume *when* any of those things will happen, and it also doesn't say that the assumption must turn out to be correct. – Rob Kennedy Jan 18 '12 at 19:57
  • If an implementation may assume something that is false, anything can happen. While not explicitly described as such, it is generally considered to be undefined behavior. – David Schwartz Jan 18 '12 at 20:05
1

This call:

thread.join();

explicitely tells your program to wait until the function the thread is executing, returns. Your function never returns, so you program never gets past this function call. You can start extra threads between the thread creation and the corresponding call to join(). For example:

#include <thread>

void someFunction() { for(volatile int x = 0; ; x = x){};}

int main()
{
    std::thread t1(someFunction);
    std::thread t2(someFunction);
    std::thread t3(someFunction);
    t1.join();
    t2.join();
    t3.join();
    return 0;
}

will spawn 3 threads that do absolutely nothing. If the functions passed to the threads do return, this is what you want to do.

If you want to have the task run and the main program exit before that, you will need to spawn a new process in a platform-dependent way, so that their execution is not stopped by your program exiting.

rubenvb
  • 74,642
  • 33
  • 187
  • 332