Threads and memory in MFC

I have a standard queue and a flush queue thread.  I have a CConnection object, and a CMessage object.

The flush queue thread pops the queue and then creates a SendMessageThread.

struct SEND_PARAMS
{
   CConnection* pConnection;
   CMessage* pMessage;
} SEND_PARAMS;

static void SendMessageThread(void* p)
{
    SEND_PARAMS pSp = (SEND_PARAMS*) p;
    CConnection* pConn = pSp->pConnection;
    CMessage* pMess = pSp->pMessage;

    // I would do send the message here
    // BUT, pMessage is an points to garbage memory

    // delete pMess; (throws an exception)
    // delete pSp; (throws an exception)
}

static void FlushQueue(void* p)
{
   while (bNotDone)
   {
       message = queue.top();

       SEND_PARAMS* pSp = new SEND_PARAMS;
       pSp->pConnection = conn;
       pSp->pMessage = new CMessage("stuff");

       HANDLE hThread = (HANDLE) _beginthread(SendMessageThread, 0, (void*) &pSp);

       queue.pop();
   }
}


The problem is that by the time the SendMessageThread function runs, the memory has already be de-allocated by the program. This behavior is only happening when using MFC.  In a normal Win32 app (non MFC) this does not happen, ie, the memory allocated in the loop for the SEND_PARAMS is not deleted until I puposefully delete it in the SendMessageThread.

So I can tell MFC has built in garbage collection.  But I need to get these params into the thread on the fly.  I don't want that memory deleted until I say so.  At this point taking MFC out of the app is not possible.  Is there any way to get the memory to 'stick'?

If you need more clarification, let me know.  Thanks, Chase707
LVL 4
Chase707Asked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
nietodConnect With a Mentor Commented:
AH.

You are passing a POINTER TO A POINTER to you send parameters
0
 
Chase707Author Commented:
Sorry, in FlushQueue

pSp->pMessage = new CMessage("stuff");
should be
pSp->pMessage = new CMessage(message);

Chase707
0
 
Chase707Author Commented:
Also, the CConnection and CMessage class do not use any MFC classes inside of them, so that is not the problem.

I know that you can't send pointers to MFC classes across thread without problems.

Chase707
0
Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

 
jkrCommented:
I guess that "conn" and "message" are related to the queue - what kind of queue is this? As you say that you are haveing problems with these objects and they are sored in a queue, the "pop()" operation might invaidate them...
0
 
jkrCommented:
>>Also, the CConnection and CMessage class do not use any MFC classes inside of them

That is another pointer to the queue...
0
 
nietodCommented:
Typically the way parameters are passed to a new thread are via the heap..  In other words, the 1st thread allocates the new parameters in a structure using operator new.   Then a pointer to this structure is passed to the new thread.  The new thread then is responsible for deleting the structure when it no longer needs the parameters.

There are other methods for doing this, but this tends to be the easiest and often the best.
0
 
Chase707Author Commented:
No, that is not the problem, as you can see, the following creates a copy of the Message class (copying every data member expicitly), before passing it in as a param to the SendMessageThread function.
pSp->pMessage = new CMessage(message);

The CConnection class is always valid for the life of the program.

Chase707
0
 
Chase707Author Commented:
neitod, that's exactly what i'm doing, isn't it?

Chase707
0
 
nietodCommented:
Wait a second, that looks liek what you are doing at least in part.   Except why not with the connection object?  The other objects should be fine, but you say they are not.  Are you sure?

0
 
nietodCommented:
>>    HANDLE hThread = (HANDLE) _beginthread(SendMessageThread, 0, (void*) &pSp);

should be

   HANDLE hThread = (HANDLE) _beginthread(SendMessageThread, 0, (void*) pSp);

Then it should work.

except I am a little concerned about the connection object.  That should be dynamcially allocated too (probably).   Can you post a little more of the code?
0
 
Chase707Author Commented:
argh....that's it exactly.  Sometimes it takes someone elses eye to see it.

Thanks.
0
 
Chase707Author Commented:
The connection object is actually located within a static list of CConnection objects, and is retrieved dynamically before the call to SendMessageThread.  So that's OK.

Thanks again.
0
 
nietodCommented:
>> Sometimes it takes someone elses eye to see it.
It took my eyes a long while to adjust.   I'm out of pratice at reading other people's code.   Its much harder than reading one's own code.

thanks.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.