Work Queue

Re: Send cancel from GUI?

6:57 8 Sep '05

hello,
i've got CWorkQueue working, but i'd like to be able to let the user cancel computation for a particular thread (as opposed to cancelling all threads with CWorkQueue::Destroy) from the GUI. i can figure out how to specify identifying information in each WorkItemBase-derived object, but how can i find and abort the correct thread from the GUI? it seems i'd have to add a method to CWorkQueue to search its list of threads, no?
ed

7:20 8 Sep '05

I'd like to clarify: could I simply save a pointer to the WorkItemBase-derived object and call its Abort method? thanks, ed
Sign In·View Thread·PermaLink

Unzip

Danny Maes

22:22 11 Aug '05

Failed to unzip file Work_Queue_src.zip. Is file corrupt ?
Sign In·View Thread·PermaLink

Handle leaks

madkoala

16:31 30 Jun '05

Thanks for your nice class. I have found that it was very helpful. But, recently I discovered that this library leaks handle. After doing job using WQ, task manager shows that 1 handle increased and not released until program ends. Look into with WinDbg, one thread handle is not being released. But, no threads are not present in WQ. Is there anyone who saw this?
Sign In·View Thread·PermaLink

Re: Handle leaks

Yves Tkaczyk

11:47 20 Oct '05

The leak is in the demo part (CWQDemoDlg::OnDestroy()) where the thread hThreade is created but never destroyed. In this method, at the end change

			} // End of else clause.
		} // End of the always while loop.
		
    
		GetDlgItem(IDC_CREATE)->EnableWindow(TRUE);
		GetDlgItem(IDC_NUMBER_OF_THREADS_SPIN_SPIN)->EnableWindow(TRUE);

with

			} // End of else clause.
		} // End of the always while loop.
		
    CloseHandle(hThreade);
    
		GetDlgItem(IDC_CREATE)->EnableWindow(TRUE);
		GetDlgItem(IDC_NUMBER_OF_THREADS_SPIN_SPIN)->EnableWindow(TRUE);

This fixes the leak.

Regards,

Yves Tkaczyk

Pass CMainFrame pointer?

6:06 17 Feb '05

I'm working on an MDI project, instead of the dialog-based example. When I create an instance of my subclass of WorkItemBase, I pass a pointer to the mainframe object, rather than a pointer to the XListCtrl object used in the example code. However, when I try to call CMainFrame methods from the thread (e.g., to indicate progress), various assertions fail regarding the validity of the CMainFrame's status bar or other handles, such as m_hWnd. Should I be using custom messages rather than passed pointers to indicate progress in my CMainFrame? If so, why is it OK to pass a pointer to the XListCtrl object in the demo code?
thanks,
ed

Dan Madden

12:15 8 Jun '05

I wouldn't use a pointer in a thread to your GUI (bad things can happen). Instead (not saying it is the best method), try posting a message to your GUI...like (from your thread):


// string message allocator for posting messages between windows...
static char* AllocBuffer(CString strMsg)
{
	int nLen = strMsg.GetLength() + 1;
	char *pBuffer = new char[nLen]; 
	strncpy(pBuffer,(const char*)strMsg, nLen);
	ASSERT(pBuffer != NULL);
	return pBuffer;
}

void SomeFunction(void)
{
...
   CString str = "Test Message";
   ::PostMessage(m_hWnd,UWM_MSG_UPDATE,(WPARAM)0,(LPARAM)AllocBuffer(str));
...
}

And have a function in your CMainFrame that reads it:


    // in your MainFrm.h
    LRESULT OnUpdate(WPARAM wParam, LPARAM lParam);

    // in your MainFrm.cpp
LRESULT CMainFrame::OnUpdate(WPARAM wParam, LPARAM lParam)
{
    char* pMsg = (char*) lParam;
    CString csMsg = pMsg;
    delete pMsg;
    ....
    // do something with it...
    ....
    return 0;
}

That is how I do it Big Grin

Regards,

Dan

9:11 25 Aug '05

It is not the accessing of the CMainFrame itself that is inherently bad, it is the accessing of the MFC GUI objects that does not work from the secondary thread.
The internal maps that map HWND to the CWND* are pretty thread-specific in MFC.
You can post or send messages to a control's HWND safely, but not via the CWND* or its derivatie classes (like the CButton, or whatever).
I typically create variables to store data that the secondary thread will update, and then post messages that the CMainFrame would retrieve, and then it reads the data.

I do not favor the method suggested elsewhere in this message thread, because posted messages are not guaranteed delivery, and your application will probably, inevitably, end up with memory leaks under any kind of heavy load.

4:36 1 Sep '05

i'm afraid i don't understand; you don't favor posting messages, yet you recommend posting "messages that the CMainFrame would retrieve". would you please explain the difference?
i've stored a pointer to the CMainFrame in my thread, and have used mainFrame->PostMessage() to handle communication between the thread and the GUI, but it seems from your post that this may lead to memory leaks....
thanks for your advice,
ed

Use CWinThread instead of ::CreateThread

4:56 1 Sep '05

I am sorry I was not more clear.

I don't favor posting message with data allocated by the sender that must be freed by the receiver, because a posted message is not guaranteed delivery. If the receiver does not get the message, then the memory is lost, and you have a memory leak.

It is better for the sender to update some queue that is shared between the sender and receiver, if the receiver never processes the message, the message data can eventually be deleted when queue is removed, cleaned up by receiver, cleaned up by sender, etc. At least the message data memory is not lost.

Let me know if this still does not make sense, and I will elaborate further.

Timeout

dspeziale

23:57 12 Dec '04

I'm using this fine class, but i have a problem with timeout support. For ex. if the duration of the job excess 2 min. i want kill it, with the complete call stack for destroy. Could you (all) help me about. Daniele
Sign In·View Thread·PermaLink

i wnt yours helpe

sultan_saud

3:55 1 Nov '04

i saw several of codes threads and processes but as you know every one how studies computer scince can't work alone with aout external help so i am bigenner student i want some simple compleste code about threads with simulation because i wnat to ceart a complete programs which can help student in the futcure e-mail: programer_2000@hotmail.com
Sign In·View Thread·PermaLink	1.00/5 (1 vote)

Andrey Del Pozo

11:22 6 Sep '04

If the threads in the pool are going to access a MFC object they must be create with AfxBeginThread (a worker thread)instead of ::CreateThread or beginthread because MFC stores certain data per thread. The real problem is that using ::CreateThread does not cause an inmediate failure it all depends in what the thread will do.

I don't have any links for a description of the problem but you can Google for it.

"I don't want to achieve immortality through my work... I want to achieve it through not dying."
Woody Allen

2.00/5 (1 vote)

Re: Use CWinThread instead of ::CreateThread

IO Completion port / QueueUserWorkItem

9:05 25 Aug '05

CreateThread -> safe if only accessing Win32 API calls -> no runtime functions and no MFC _beginthradex -> safe if accessing Win32 API calls and C runtime functions -> No MFC AfxBeginThread -> safe if accessing Win32 API calls, C runtime functions, and MFC You end up with unitiialized thread specific variables and subsequent memory leaks if you do not start the threads with the proper functions.
Sign In·View Thread·PermaLink	3.00/5 (1 vote)

Vladislav Gelfer

11:42 6 Jun '04

The idea is elegant, you are right. Every good programmer should discover such a pattern Smile

Now, about the performance. If you're not limited by win9x platforms you can (and should) use more sophisticated thread-managing tools.

IO Completion ports. This kernel object acts similar to what you've done, but its main goal is to minimize the count of context switches, hence it is more effective. Every thread in the pool should await its turn by calling GetQueuedCompletionStatus(), whereas you post tasks (and the termination instruction at the end) by PostQueuedCompletionStatus().

QueueUserWorkItem. Honestly speaking I've never used it myself, but as far as I know this creature is similar to IO completion ports, however it adjusts the number of threads in its pool automatically (collects statistics), so it is believed to work even better. However as for me, I would prefer to make statistics myself Smile

2.00/5 (1 vote)

Memory Problem with AdoConnection

VietDelphi

6:08 7 May '04

Hi.

I´m using this class, and its work very god.

However, when a WorkItemQueue uses an ADOConnection (by a pointer) the memory of the application grows 4k.

That Varible is declared with : _ConnectionPtr pConn;

And the constructor is :

STLogLatido::STLogLatido(CString m, _ConnectionPtr c, CProgressCtrl*	pr)
{
	pConn = c;
	msg = m;
	
	
	m_prgbar = pr;
	m_prgbar->SetPos(m_prgbar->GetPos() + 1);
}

I create the WorkItem with:


	Queue.InsertWorkItem(new STLogLatido(m, pConn_Log, &m_barra));

I´ve posted the problem here:http://www.codeproject.com/script/comments/forums.asp?forumid=1647&select=814385&fr=51&msg=814385#xx813863xx

I need to resolve the problem..... please help Cry

Re: Memory Problem with AdoConnection