MFC + Threading = C2665 - C / C++ / MFC Discussion Boards

Re: Obtaining process name from process handle

hxhl9520-Mar-09 6:08

20-Mar-09 6:08

winbase.h doesn't contain a definition of GetProcessId. I tried defining it manually with DWORD WINAPI GetProcessId(__in HANDLE ProcessHandle), but then I get an unresolved external symbol error, even though I'm obviously including kernel32.lib...

Re: Obtaining process name from process handle

David Crow20-Mar-09 7:16

David Crow

20-Mar-09 7:16

hxhl95 wrote:
winbase.h doesn't contain a definition of GetProcessId.

You need to install the Platform SDK.

"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

Re: Obtaining process name from process handle

hxhl9520-Mar-09 7:23

hxhl95

20-Mar-09 7:23

I have.

Re: Obtaining process name from process handle

David Crow20-Mar-09 7:31

David Crow

20-Mar-09 7:31

So are you looking in C:\Program Files\Microsoft SDK\include\winbase.h instead of C:\Program Files\Microsoft Visual Studio\VC98\Include\winbase.h? If you add #include <winbase.h></winbase.h> to the top of a file, right-click it and select Open, which of the two files opens?

Re: Obtaining process name from process handle

hxhl9520-Mar-09 8:04

hxhl95

20-Mar-09 8:04

I did

#include <C:\Program Files\Microsoft Platform SDK\Include\winbase.h><br />

just in case, and it's still giving me an undeclared error. When I open the file the SDK file opens, and I can see the definition of GetProcessId in the file. However the compiler just doesn't find it. Sigh | :sigh:

Re: Obtaining process name from process handle

David Crow20-Mar-09 8:16

David Crow

20-Mar-09 8:16

I'm out of suggestions at this point. This compiles fine for me:

#include <windows.h>
 
void main( void )
{
    GetProcessId(0);
}

Re: Obtaining process name from process handle

hxhl9520-Mar-09 10:08

hxhl95

20-Mar-09 10:08

Okay. I'll just try a different approach if I can't get this working by tomorrow.

Thanks a lot for your help Smile | :)

MFC + Threading = C2665

Killiconn19-Mar-09 14:43

Killiconn

19-Mar-09 14:43

I have been surfing the web trying to find a solution and I've tried some of them and still can't compile. It is a standard VS generated DlgClass and I just want to launch the worker which is prototyped up top as global. I've tried casting ExecuteThread every way possible pretty much in the thread launch function. Any obvious solutions?

// Prototypes:
void ExecuteThread(LPVOID lParam)


// Button to launch the worker:
void CVisualEmulatorDlg::OnBnClickedRun()
{
	HWND hWnd = GetSafeHwnd();

	CWinThread *pThread = AfxBeginThread(ExecuteThread, hWnd, THREAD_PRIORITY_NORMAL);
	
	//cpu->Execute();
}

// Worker Thread:
void ExecuteThread(LPVOID lParam)
{

        //cpu->Execute();

	MessageBox( (HWND)lParam, (LPCWSTR)"Thread Start", (LPCWSTR)"Secondary Thread", MB_OK );
	return;
}

Re: MFC + Threading = C2665

«_Superman_»19-Mar-09 19:03

«_Superman_»

19-Mar-09 19:03

You haven't been reading your documentation!!! Poke tongue | ;-P

Try this.

UINT __cdecl ExecuteThread( LPVOID pParam );

«_Superman_»
I love work. It gives me something to do between weekends.

Re: MFC + Threading = C2665

Killiconn20-Mar-09 10:50

Killiconn

20-Mar-09 10:50

The reason I ended up trying void, along with any other things is that UNIT dosn't show up as a data type. Is there a header that needs to be included? Having trouble researching it because everything that comes back is about unit testing.

From one page it looked like UNIT meant use, int, long, or short, but tried and non of those worked. Tried with and without the __cdecl as well.

Never come across the UNIT before and wishing right now I never had. Code looks basically the same. Any ideas?

// Launcher
void CVisualEmulatorDlg::OnBnClickedRun()
{
	HWND hWnd = GetSafeHwnd();

	CWinThread *pThread = AfxBeginThread(ExecuteThread, hWnd, THREAD_PRIORITY_NORMAL);
	
	//cpu->Execute();
}

// Worker
UNIT __cdecl ExecuteThread(LPVOID lParam)
{
	MessageBox( (HWND)lParam, (LPCWSTR)"Thread Start", (LPCWSTR)"Secondary Thread", MB_OK );
}

Re: MFC + Threading = C2665

«_Superman_»21-Mar-09 3:34

«_Superman_»

21-Mar-09 3:34

typo typo typo typo

Its UINT not UNIT.

«_Superman_»
I love work. It gives me something to do between weekends.

Re: MFC + Threading = C2665

Killiconn21-Mar-09 10:01

Killiconn

21-Mar-09 10:01

Wow.. sorry guys. Pretty embarased right now...but that fixed it.

Thanks a lot.

Re: MFC + Threading = C2665

_AnsHUMAN_ 19-Mar-09 19:08

_AnsHUMAN_

19-Mar-09 19:08

Killiconn wrote:

void ExecuteThread(LPVOID lParam)

Are you missing the ';' behind the function declaration.
By the way what are the compilation errors that you get?
The possible solutions for C2665 are
* Supply a conversion operator.
* Use explicit conversion.

but can't really say if they help you in resolving your problem

You need to google first, if you have "It's urgent please" mentioned in your question.
Wink | ;-)

_AnShUmAn_

Re: MFC + Threading = C2665

Sunil Lanke19-Mar-09 19:09

Sunil Lanke

19-Mar-09 19:09

Your worker thread function definition is wrong, check out here[^]

The function should not return void, the function signature should be as follows:

UINT __cdecl MyControllingFunction( LPVOID pParam );

Another Post from Bob about Threads, Pointers and Locks[modified]

BobInNJ19-Mar-09 10:45

BobInNJ

19-Mar-09 10:45

I am currently writing a multi-threaded application using C++ and MFC. I am trying to write some code to keep track of my memory allocations (new) and my memory frees (delete). I have written aclass called MemoryChecker that is suppose to do this. To store the list of pointers that are allocated,
I am using STL which is not thread safe. To make it thread safe, I put a call to WaitForSingleObject
around the body of the function. I would expect to make this thread safe. Inside the member function
deleteItem, there is a static variable. It is initialized to true but later set to false. Before it is set to false, there is an assert statement that checks that the value is still true. However,
that assert statement is failing (sometimes). Therefore, I am thinking my lock is not working properly.

<br />
void<br />
MemoryChecker::deleteItem( void *ptr )<br />
{<br />
    if ( WaitForSingleObject(mutexDeleteHandle, INFINITE) == WAIT_OBJECT_0 ) {<br />
	if ( ptr == 0 ) {<br />
	    ReleaseMutex(mutexDeleteHandle);<br />
	    returneturn;<br />
	}<br />
	static bool go = true;<br />
	bool found = false;<br />
	NewList::iterator it = newList.begin();<br />
	while ( it != newList.end() ) {<br />
		if ( it->ptrValue == ptr ) {<br />
			found = true;<br />
			break;<br />
		}<br />
		it ++;<br />
	}<br />
	if ( found == false )<br />
		found = true;<br />
	else {<br />
		assert( found );<br />
		newList.erase( it );<br />
	}<br />
	assert( go );<br />
	go = false;<br />
	ReleaseMutex(mutexDeleteHandle);<br />
}<br />
}

I should also tell you that I create the lock, in another thread, with the following call:

mutexDeleteHandle = CreateMutex( NULL, FALSE, NULL );

Please note that the second parameter in CreateMutex is to specify who owns the lock and the
lock may not be owned by the thread making the call to WaitForSingleObject.

I am hoping that somebody here can tell me what I am doing wrong.

Thanks

Bob

modified on Thursday, March 19, 2009 6:26 PM

Re: Another Post from Bob about Threads and Points

Code-o-mat19-Mar-09 12:31

Code-o-mat

19-Mar-09 12:31

Your 'go' variable is static, it will be set to true once, so after you do 'go = false' it will remain false in following calls too.

p.s: Please put all of your code between <pre> and </pre> tags to make it easier to read.

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <

Re: Another Post from Bob about Threads and Points

BobInNJ19-Mar-09 12:39

BobInNJ

19-Mar-09 12:39

Thanks for the response. You are 100% right. I am not awake today. I need to reinitialize the go flag every time to make it a valid test.

Now for your second point. I put the code between <pre> and </pre> but it did not preserve the white spacing. I do not know why. Any ideas?

Bob

Re: Another Post from Bob about Threads and Points

bulg19-Mar-09 13:39

bulg

19-Mar-09 13:39

Sorry, I see one small <pre> tag, and a large, only-half-there <code> tag.

Re: Another Post from Bob about Threads and Points

BobInNJ19-Mar-09 13:58

BobInNJ

19-Mar-09 13:58

blug,

Thanks for the response. I am not sure. Before I include code, I click on the formatting option code block. That is the option just to the left of inline code and to the right of BIG. Maybe, I should click on inline code and paste my code in there. Not Sure.

Bob

Threads and Pointers

BobInNJ19-Mar-09 7:36

BobInNJ

19-Mar-09 7:36

I am currently developing a multi-threaded application using C++ and MFC. Each thread calls new and delete to allocate and free memory. I am wondering if this is ok. In particular, if I have a routine that does the following, is it thread safe?

<br />
void<br />
WorkerClass::genRandomNumbers( double *randomNumbers, int count )<br />
{	<br />
    double *ranList = new double[6];<br />
<br />
    // Do some work, details not shown<br />
<br />
    delete []ranList;<br />
}<br />

I am thinking that if two different threads are executing this routine at the same time, one might be allocating memory and the other freeing memory. Is that ok? One possibility is that Microsoft has put locks in there code to make sure that new and delete are thread safe. I have been unable to find documentation saying that they have or have not done this. I am hoping somebody out there can enlighten me on this issue.

Thanks

Bob

Re: Threads and Pointers

led mike19-Mar-09 7:41

led mike

19-Mar-09 7:41

BobInNJ wrote:
I am thinking that

My advice is not to use your own thinking about how multi-threading works. I strongly urge you to find some material designed to explain or teach multi-threading concepts and study it.

If this is something you decide to do, I can tell you that back when was starting out with threading I found this book[^] (the chapters on threading) very helpful. It was the first edition and I can't verify for you that the new editions contain the same material.

Re: Threads and Pointers

Eytukan19-Mar-09 7:41

Eytukan

19-Mar-09 7:41

Perfectly safe. Unless you allocate something static. like

void
WorkerClass::genRandomNumbers( double *randomNumbers, int count )
{
 static int i =0; //Not safe.

 i = blahaha

}

He never answers anyone who replies to him. I've taken to calling him a retard, which is not fair to retards everywhere.-Christian Graus

Re: Threads and Pointers

led mike19-Mar-09 7:58

led mike

19-Mar-09 7:58

VuNic wrote:
Perfectly safe

Really? Even though you have no idea what is happening in the "details not shown"?

Re: Threads and Pointers

Eytukan19-Mar-09 8:12

Eytukan

19-Mar-09 8:12

Oops! that was not to negate your message up there.. as you see it's all posted at the same time. Smile | :)

"Perfectly-Safe" is perfectly restricted to that block of code he posted. Certainly I wanted to add a note asking him to look at the JR book you hrefed. but felt quite lazy to edit the text again Roll eyes | :rolleyes:

He never answers anyone who replies to him. I've taken to calling him a retard, which is not fair to retards everywhere.-Christian Graus

Re: Threads and Pointers

CPallini19-Mar-09 7:46

CPallini

19-Mar-09 7:46

Automatic variables (like ranlist) are thread safe.
Smile | :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

[My articles]

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.