CriticalSection DeadLock ?...

[khaldoun KASSEM]

Hi to all

I am using CriticalSections in a MFC based application

I have a dialog, containing a CListCtrl. I use a thread to fill the list because it contains 5000 elements and I don't want to block my dialog when I fill it.
I pass a pointer to my dialog object to the thread.

in the thread I use criticalsection to limit access to the listCtrl,
and in my dialog I limit access to the listctrl by the same criticalsection.

sometimes I get deadlocks??

What happens when a thread access the listCtrl to fill it, and the user clic on it???

CMyListCtrl::Onclick()
{
EnterCriticalSection(m_pSection);
////Do something with the list
LeaveCtriticalSection(m_pSection);
}

MyThread(LPVOID lParam)
{
CMyDialog *pDlg = (CMyDialog*)lParam;
if(pDlg)
{
EnterCriticalSection(pDlg->m_pSection);

/////Do something with the m_pDlg->m_listCtrl takes 1-2 secondes
/// TAG 1

LeaveCriticalSection(pDlg->m_pSection);
}
}

When the Thread is at TAG 1, and I clic on the list I get the deadlock?
any Idea?

Thank you

[leojose]

What happens when a thread access the listCtrl to fill it, and the user clic on it???

Your application will go into a wait mode (for 2 seconds) before the click operation gets processed.

When you say 'deadlock' are you referring to an infinite waiting state?

[khaldoun KASSEM]

Thank you

When you say 'deadlock' are you referring to an infinite waiting state?

Yes, The MFC Dialog blocks and I must kill my process.

I think its a problem with the user interface mesages, because when I use the same mechnism in two working threads without UI, it works very well?..

[khaldoun KASSEM]

Hi Again

the problem is :
When I EnterCriticalSection in a worker Thread, and before LeaveCriticalSection I try to EnterCriticalSection in the main dialog it blocks...
The thread stops and don't call his Leave and the dialog block on his Enter waiting for the leave?...

Thank you

[kirants]

It is expected. Your dialog's thread has to pump window messages for it to remain responsive , since it has UI elements. When that is not happening ( since you are blocked on EnterCriticalSection ), you get the feeling that it is hung, when in fact it is not ( Note, this is not a deadlock scenario ).

You need to decide what you wanna do in such a situation. i.e. if the worker thread is using the listcontrol and you click on the dialog, what do you want to do ?
You have 2 options,

• block , as you are doing now , with EnterCriticalSection, or,
• try to get the list control , if not do nothing. You can do this by TryEnterCriticalSection

[googler]

Does it take 1-2 seconds to populate the list because it has 5000 elements or because of the processing time needed to build the list? I would suggest to use a design in the worker thread where it builds a shadow copy of the list instead of the actual list. Then, when the shadow list is ready, the thread locks the critical section, populates the list, and releases the critical section. This should minimize the delay.

[Arjay]

Hi Again

the problem is :
When I EnterCriticalSection in a worker Thread, and before LeaveCriticalSection I try to EnterCriticalSection in the main dialog it blocks...
The thread stops and don't call his Leave and the dialog block on his Enter waiting for the leave?...

Thank you

One of the fundamental problems is that you are accessing a MFC UI component from a secondary thread. You aren't allowed to do that. With that in mind, I suggest a slight change of approach:
1) Limit UI component access to the main thread
2) Use a windows message to signal the main thread UI components to populate the control
3) Use a virtual list-view rather than the regular list-view (or listbox) control.

This thread contains code for a LVSelState sample. This sample is a virtual list-view control that maintains an stl list of items populated by a secondary thread. By default, the list is filled with 10,000 items, but a user can change this via a spin control to over a million items. 1 millions items take a while to generate, but while the list is being created by the secondary thread, the UI remains responsive (and the user can cancel the operation or close the dialog at any time).

The neat thing about using the virtual list-view control is that, unlike the regular control, scrolling the virtual control with alot of items is very fast.

Arjay

[khaldoun KASSEM]

You need to decide what you wanna do in such a situation. i.e. if the worker thread is using the listcontrol and you click on the dialog, what do you want to do ?

I want my dialog to be movable, and to do his painting stuf "OnPaint()"...
I disable all controls in my dialog (in the worker Thread), and enable them when it end.

Does it take 1-2 seconds to populate the list because it has 5000 elements or because of the processing time needed to build the list?

The worker Thread read Informations from a DB (access DB using CRecrodsets) and puts them in the listctrl, so I read data record by record and i add to the list.

Every time I call the EnterCriticalSection from a worker thread, and at the same time from the UI dialog i have a hang. and its realy a blocking situation, I can do nothing when I get it, and I must kill the process...

Thank you

[khaldoun KASSEM]

3) Use a virtual list-view rather than the regular list-view (or listbox) control.

I am using virtual list ctrl, and its fast to add elements to it,
but when I get elements from database it takes more time to finish.


thank you

[Arjay]

I am using virtual list ctrl, and its fast to add elements to it,
but when I get elements from database it takes more time to finish.


thank you

Check out the link I provided to the sample earlier. It's doing pretty much the same lengthy operation in a secondary thread, except the dialog doesn't hang while this is going on. Look at the sample to find out how it's doing it.

Arjay

[MikeAThon]

....

CMyListCtrl::Onclick()
{
EnterCriticalSection(m_pSection);
////Do something with the list
LeaveCtriticalSection(m_pSection);
}

MyThread(LPVOID lParam)
{
CMyDialog *pDlg = (CMyDialog*)lParam;
if(pDlg)
{
EnterCriticalSection(pDlg->m_pSection);

/////Do something with the m_pDlg->m_listCtrl takes 1-2 secondes
/// TAG 1

LeaveCriticalSection(pDlg->m_pSection);
}
}

When the Thread is at TAG 1, and I clic on the list I get the deadlock?
any Idea?

Thank you

Please describe the "something" that you are doing in the thread. Code would be good.

If part of the "something" involves sending of messages to the list control, then it's fairly clear why you get a deadlock. Consider this: Your worker thread has the critical section, and it sends a message to the control. Your UI thread is the only thread that can process the message (since it's the thread that created the control's window), so your worker thread does nothing until the OS switches thread context to the UI thread and the UI thread processes the message, together with any onther messages in the UI's message queue. Normally, there would be thread switch back to the worker thread which would then continue on its merry way. But if the UI thread has an OnClick message in its queue, the UI thread now tries to get the critical section. It can't because the worker thread has it, so the UI thread blocks. But while it's blocking, it also can't process any messages, including the messages being sent by the worker thread. Presto, you get a deadlock, since the worker thread can't do anything either, until the UI thread processes its messages.

Incidentally, you might be sending messages from the worker to the UI thread without realizing it, if you call fucntions like CListCtrl::InsertItem. The MFC framework for this function is a simple wrapper around SendMessage( m_hWndOfTheListControl, LVM_INSERITEM, 0, &LVITEM), which obviously sends a message.

Mike

[khaldoun KASSEM]

Incidentally, you might be sending messages from the worker to the UI thread without realizing it, if you call fucntions like CListCtrl::InsertItem. The MFC framework for this function is a simple wrapper around SendMessage( m_hWndOfTheListControl, LVM_INSERITEM, 0, &LVITEM), which obviously sends a message.

Mike

Thank you for this explanation and I think this is my problem
I am trying to find a solution, and looking to the sample sent by Arjay

Thank you

[MrViggy]

Hi to all

I am using CriticalSections in a MFC based application

I have a dialog, containing a CListCtrl. I use a thread to fill the list because it contains 5000 elements and I don't want to block my dialog when I fill it.
I pass a pointer to my dialog object to the thread.

in the thread I use criticalsection to limit access to the listCtrl,
and in my dialog I limit access to the listctrl by the same criticalsection.

sometimes I get deadlocks??

What happens when a thread access the listCtrl to fill it, and the user clic on it???

CMyListCtrl::Onclick()
{
EnterCriticalSection(m_pSection);
////Do something with the list
LeaveCtriticalSection(m_pSection);
}

MyThread(LPVOID lParam)
{
CMyDialog *pDlg = (CMyDialog*)lParam;
if(pDlg)
{
EnterCriticalSection(pDlg->m_pSection);

/////Do something with the m_pDlg->m_listCtrl takes 1-2 secondes
/// TAG 1

LeaveCriticalSection(pDlg->m_pSection);
}
}

When the Thread is at TAG 1, and I clic on the list I get the deadlock?
any Idea?

Thank you

I'm kinda surprised this hasn't been brought up already. If this is an MFC based dialog, with MFC based widgets (like MikeAThon alluded to), then you should not be passing the pointer to the object! MFC objects are not thread safe. You should pass the handle to the list control, and use PostMessage to fill the control.

Viggy

[Arjay]

I'm kinda surprised this hasn't been brought up already.

It was brought up in my first post