Sharing memory Thread<->Process

[marsface]

Hello Coders,

i don't have any expirence in win32 threads, but some
background in programmig

My question is how do i share memory (varaibles) between
the creator of the thread and the thread itself.

Here a pseudo code:

unsigned long bytes;

thread = CreateThread(..,..,..,)

while (Bytes < 1024)
printf("Bytes: %ld\n"),

..
.

Thread Code:
{
bytes++;
}


I hope the principle is understandable ?? :-)

Best Regards,
Robert

[Fordy]

The easiest, least sloppy way is to use the lpParameter on CreateThread()...

Cast the data you want to send to LVOID (you can send a pointer to whatever), and recast it to what you want in the tread proc

#include <windows.h>

DWORD WINAPI ThreadFunc(LPVOID lParam){
	MessageBox(HWND_DESKTOP,(LPSTR)lParam,NULL,MB_OK);
	return 0;
}


int main(void){

	DWORD dwTID;
	HANDLE hThread;
	char buff[] = "Hello from thread!!!!";

	hThread = CreateThread(NULL,NULL,ThreadFunc,(LPVOID)buff,NULL,&dwTID);
	WaitForSingleObject(hThread,INFINITE);//let thread end
	return 0;
}

As a word of caution, beware CreateThread when using std functions.......Your compiler will most likely have a better safer version of the func (__beginthreadex() in VC++)

[marsface]

Thanks, that help,

but what is the difference in detail when i use
the (__beginthreadex()) function instead of the
API call CreateThread ???


Regards,
Robert

[Fordy]

Some functions from the std libs arent thread safe as they do stuff like use global buffers...etc.....

So when your main thread and the created thread both call certain std funcs there is a small risk of corruption, leaks or exceptions from dereferncing NULL pointers etc........

With __beginthreadex(), the multithreaded versions of the std libs are linked instead of the standard versions......then it calls CreateThread() to create the thread itself.......

It's often not a problem....but if you get into the habit of using __beginthreadex() your life will be easier...

#include <windows.h>
#include <process.h>//Need this


UINT __stdcall ThreadFunc(LPVOID lParam){
	MessageBox(HWND_DESKTOP,(LPSTR)lParam,NULL,MB_OK);
	return 0;
}


int main(void){

	UINT uiTID;
	HANDLE hThread;
	char buff[] = "Hello from thread!!!!";

	hThread = (HANDLE)_beginthreadex(NULL,NULL,ThreadFunc,(LPVOID)buff,NULL,&uiTID);
	WaitForSingleObject(hThread,INFINITE);
	return 0;
}

To use this code example in VC++, go to project->settings->C/C++->Category->Code Generation->Use Runtime Library->MultiThreaded

[adrianxw]

I would also advocate the beginthread() or beginthreadex() functions, (Note, beginthreadex() is called beginthreadNT() on a Borland compiler).

However, there is a difference between beginthread() and beginthreadex() in that beginthread() closes the thread handle for you when the thread exits, beginthreadex() does not. If you are running an app which is spinning lots of threads over time, use CloseHandle() to close the handle when the thread exits or you will leak handles.

[Fordy]

Originally posted by adrianxw
I would also advocate the beginthread() or beginthreadex() functions, (Note, beginthreadex() is called beginthreadNT() on a Borland compiler).

However, there is a difference between beginthread() and beginthreadex() in that beginthread() closes the thread handle for you when the thread exits, beginthreadex() does not. If you are running an app which is spinning lots of threads over time, use CloseHandle() to close the handle when the thread exits or you will leak handles.

He he...yeah I heard that, but from a different viewpoint....

In Jeff Richter's book Advanced Windows he states the _beingthreadex & _endthreadex superceded _beginthread & _endthread.....

The reason M$ brought them out was that people still cared about the thread's return value, and a call to GetExitCodeThread() after the thread died would fail as _endthread had called CloseHandle() as you said......

But I agree with your point that an app with multiple threads should ensure that housekeeping is done by periodically releasing these handles.......

[marsface]

Thanks a lot guys!!

Regards,
Robert