Quote: Haha but all these solutions look difficult to me.
Because I never done multithreading before.
I found a site which had an abstract thread but I don't know how to use it.

They could look like, but I hope you'll find it easier after reading this.
Point 1: do not use wrappers, unless you did them yourself.
When you use threading, you're really saying "I 4/\/\ r0xx0|2" so you really must get your hands dirty with to good ol' win32 calls.
As you'll see, the calls are quite easy and trying to wrap them completely would probably be overkill.
So, in other words, you cannot go around saying you multithreading and then expect some magic lib to do your work efficiently. Threading is low-level stuff and you have to know what's happening behind the scenes for the sake of efficiency. If you don't want to know, you can use wrappers but if something goes awry, you were the one aiming at the foot.

Quote: By the way, I am using visual studio.

Point 2: you need to get your hands dirty so make sure you're compiling native code and using the last MS platform SDK.
VC2005 express, freely available from MS does not compile to win32 by default.
Canonical URL: native win32 code with VC2005 Express

After you have everything set up and running, Point 3 it's cruch time.
You'll have your "main" doing something... an the other thread doing something other enclosed where? Threads in win32 are special functions (you can also use standard C threads but I feel simply better with the native win32 ones).
Canonical URL: Process and thread functions for win32 (but you'll be much happier with the platform documentation which comes with the PSDK).

Starting a thread takes calling CreateThread with the right parameters. Quick reference:

1. lpThreadAttributes is NULL.


2. dwStackSize is 0.


3. lpStartAddress is a pointer to your routine. All it takes is a "special" function withouth the function call operator - that is, without the (), name only.


4. lpParameter
is a pointer to an arbitrary buffer. It'll likely take a few casts (yes, ugly, unsafe C casts) so you may need a bit of sugar to digest this one. I usually pass object pointers here for example. All the parameters should be there in short.

5. dwCreationFlags specify if the thread should run immediatly or not (maybe other less useful things). I usually set this to 0.


6. lpThreadId is a thread identifier I don't really like... I usually set it to NULL but you may want to keep it. I find the returned HANDLE to be much more powerful.

What about your "special" thread function? Nothing really special. It just needs to be a stdcall (WINAPI) returning 32bit uint (DWORD) and taking a void* (LPVOID).

If you want to put your thread in a object, you have to use a static function (which will become stdcall instead of thiscall). You should then pass the this pointer as the LPVOID parameter. When the thread starts, it'll take the object pointer from its private stack and live with it.

Take care: everything in the thread is private to it so local variables don't mess up each other. Global variables however means trouble: they do mess each other. Use Thread-Local-Storage for thread-local global variables or find a way to manage the issue (I find this easier).

Test the threads do work. For example, make 'em printf something to console or create and fill two different files... or a single file with 0 and 1.

After this has proven to work, you need to work out the communications. This takes the function named above so, CRITICAL_SECTION objects, CreateEvent, WaitForMultipleObjects[Ex]...