CreateThread() too slow

Hi,
I'm trying to create a basic multi-threading application in C++. The problem is CreateThread() is too slow. Worse still, it doesn't appear to halt my program while the new thread is created, the code after CreateThread() gets executed before the thread is ready. I use Beep() just for debugging purposes. My code is below:

Code:

#include <windows.h>
#include <tlhelp32.h>

DWORD WINAPI runThread(LPVOID args);
bool isThreadReady = false;

int main()
{
	DWORD dwGenericThread;
	HANDLE hThread = CreateThread(NULL, 0, runThread, NULL, 0, &dwGenericThread);

	if (isThreadReady == true)
		Beep(523, 200);

	CloseHandle(hThread);
	return 0;
}

DWORD WINAPI runThread(LPVOID args)
{
	isThreadReady = true;
	//Beep(523, 200);
	return 0;
}

Originally Posted by Mimo

Worse still, it doesn't appear to halt my program while the new thread is created, the code after CreateThread() gets executed before the thread is ready.

Well, yes.

Originally Posted by MSDN

Synchronizing Execution of Multiple Threads (Windows)
CreateProcess returns without waiting for the child process to complete its initialization.

WaitForInputIdle is the suggestion on that same MSDN page.

On a side note, you should use _beginthreadex in place of CreateThread in case you're using any CRT functions (to prevent memory leaks). At least that use to be the case, anyway.

After you call CreateThread all it has to do is return the HANDLE and do a simple boolean comparison. That's very very fast, so it's hardly that creating the thread is slow (which if the case, is one of the reasons thread pools are common place). Think about it asynchronously, CreateThread has to go through a fair amount of instructions along side your 1 line, which is faster? You could of course do it the correct way as suggested above, or the lazy way (if you're testing) would be to use Sleep(1000) or something. You might like the boost::thread interface more, although it probably just wraps CreateThread and in my case seems to act oddly sometimes.

I wonder if setting dwGenericThread to zero before creating the thread and then testing it in a loop afterwards would be sufficient? EDIT: Come to think of it, that probably won't work. Nevermind me...

As has been mentioned and recommended by Microsoft in their help for CreateThread() you should prefer to use _beginthread() or _beginthreadex().

Originally Posted by Mimo

Hi,
I'm trying to create a basic multi-threading application in C++. The problem is CreateThread() is too slow. Worse still, it doesn't appear to halt my program while the new thread is created, the code after CreateThread() gets executed before the thread is ready. I use Beep() just for debugging purposes. My code is below:

Code:

#include <windows.h>
#include <tlhelp32.h>

DWORD WINAPI runThread(LPVOID args);
bool isThreadReady = false;

int main()
{
	DWORD dwGenericThread;
	HANDLE hThread = CreateThread(NULL, 0, runThread, NULL, 0, &dwGenericThread);

	if (isThreadReady == true)
		Beep(523, 200);

	CloseHandle(hThread);
	return 0;
}

DWORD WINAPI runThread(LPVOID args)
{
	isThreadReady = true;
	//Beep(523, 200);
	return 0;
}

What you're really saying is that CreateThread is too fast, i.e. it returns before the thread it created has started executing any of its code. That's the way it's supposed to work. It isn't supposed to pause the current thread, wait for the new thread to be set up, perform a context switch to the new thread, run a certain number of lines of code, and perform another context switch back to the original thread. It would have a much longer name if it were supposed to do all of those things. Besides, it's not supposed to cause that kind of large performance hit. The whole point of threading is for different threads to do stuff at about the same time, so why should the original thread be made to wait?

If you want to do all of that synchronisation stuff then you have to do it yourself. Typical method would be to use CreateEvent, WaitForSingleObject, and CloseHandle in the original thread and SetEvent in the spawned thread.

Originally Posted by Mimo

The problem is CreateThread() is too slow.
Worse still, ... the code after CreateThread() gets executed before the thread is ready.

These two statements do not agree with one another.

Createthread() only creates the thread, it doesn't immediately execute it. It schedules it for execution. You cannot assume that threads are synchronous, they are not, they are asynchronous. You need to use critical sections or MUTEX's to fix the behavior you mention.

Oh, and createthread is as fast as you can possibly get. It executes in something like 30 instruction cycles. You are misperceiving ti as slow because your thread doesn't begin execution immediately. That has nothing to do with the speed of creatthread, it has to do with the task manager and how it schedules threads fro execution.

Thanks for your help! I'm rather new to C++, I'm used to .NET doing my bidding for me. Anyway, I tried WaitForSingleObject; it seemed like the easiest solution to my problem. It worked great in my test application, but when I went to deploy it in my real application it froze. I forgot to mention that all of my code is done under DllMain. I read some reports that using WaitForSingleObject in a dll will cause a deadlock (which it did for me). For now I'm going to look into _beginthreadex, as I do use sprintf_s.

WaitForSingleObject on a thread handle will wait for the thread to terminate, which is *not* what you want. (What's the point in creating a thread and then immediately blocking until it finishes? You might as well do the calculation in the origin thread.)

The typical way to wait for a thread to have started is to use an event.

Code:

HANDLE g_initfinished;

void threadfunc() // or whatever the correct prototype is
{
  // do initialization
  SetEvent(g_initfinished); // signal that we're done initializing
  // do actual calculation
}

void creater()
{
  g_initfinished = CreateEvent(/* params for an initially unsignaled event */);
  HANDLE thread = _beginthreadex(&threadfunc, ...);
  WaitForSingleObject(g_initfinished);
  // thread has finished initialization
}

Thanks for your reply. I tried your code and it worked great in my test application, but unfortunately it caused a deadlock again. I found this this which states that what I am trying to do is impossible . Oh well, thank you all for your help .

Why not just go back to the original design and loop on the flag?

Code:

#include <windows.h>
#include <tlhelp32.h>

DWORD WINAPI runThread(LPVOID args);
bool isThreadReady = false;

int main()
{
	DWORD dwGenericThread;
	HANDLE hThread = CreateThread(NULL, 0, runThread, NULL, 0, &dwGenericThread);

	while (!isThreadReady)
		Sleep(0);

	CloseHandle(hThread);
	return 0;
}

DWORD WINAPI runThread(LPVOID args)
{
	isThreadReady = true;
	//Beep(523, 200);
	return 0;
}

EDIT:
Also, I know it was just test code you posted, but you should never close a handle to a thread unless you know it's completed (use GetExitCodeThread and compare result with STILL_ACTIVE).

>> Why not just go back to the original design...
Because it's incorrect, due to unsynchronized access to the same memory location.

And because there is no "solution" when creating threads (or waiting for them to exit) within the context of DllMain - which is apparently what Mimo is doing.

gg

Originally Posted by Codeplug

>> Why not just go back to the original design...
Because it's incorrect, due to unsynchronized access to the same memory location.

And because there is no "solution" when creating threads (or waiting for them to exit) within the context of DllMain - which is apparently what Mimo is doing.

gg

As I understood it he wasn't waiting for the thread to finish (which is only a problem because LoadLibraryXXX won't wait forever for DllMain to complete). And as far as unsynchonized access goes, I would normally agree, but in this case the flag (1) is initialized before the thread starts, (2) is only written to by the thread after the CreateThread call, (3) is a boolean value, so there is no problem with misinterpreted bit patterns. So it's a rare situation where synchonization really isn't necessary.

Originally Posted by Mimo

Thanks for your reply. I tried your code and it worked great in my test application, but unfortunately it caused a deadlock again. I found this this which states that what I am trying to do is impossible . Oh well, thank you all for your help .

I shall quote part of the reply you linked to:

If you find yourself needing to be able to wait on threads in DllMain, then your design is just not done correctly

In addition though, the problem has nothing to do with WaitForSingleObject. It will not work like as you plan to do it no matter how you do your synchronisation.
What you're doing is horribly broken; Find another way.