Thread: deadlocking, not sure why...

here's the main code that populates a vector

Code:

// handle incoming data
boost::lock_guard<boost::recursive_mutex> lock(__mutex);
m_data.push_back(data); // vector of strings
m_lb.AddString(item); // MFC CListBox
m_lb.SetCurSel(m_data.size() - 1);
OnListBoxChanged(); // event handler for CListBox

the event handler

Code:

void OnListBoxChanged()
{
  boost::lock_guard<boost::recursive_mutex> lock(__mutex);
  int index = m_lb.GetCurSel();
  m_txt.SetWindowText(m_data[index]); // a textbox
}

ok, so data is coming in really fast, and the program auto refreshes the dialog so that the textbox is updated. if at that time i click on another item in the listbox, it triggers the OnListBoxChanged event, and then it deadlocks. also, it doesn't happen easily...what i mean is i have to click the listbox as fast as humanly possible for it to deadlock.

the thing i don't understand is....there's only 1 mutex!!! why's the program still deadlocking?

Don't have experience with these things. But looking at http://www.boost.org/doc/libs/1_35_0...cks.lock_guard just to learn, I see that there is an exception for guard_lock, because it calls lock(). So, you know, check for exceptions to see what is going on. Or try another lock. Maybe unique_lock?

I don't see an error to your logic, so try to see what happens...

actually, it's exception safe, it doesn't throw any exceptions. if you use the helper function boost::try_lock(...) that will throw an exception.

i thought maybe it was something weird with boost (highly unlikely of course), so i tried it with InitializeCriticalSection, EnterCriticalSection, and LeaveCriticalSection and the same thing occurred.

the read data thread that i've posted code is locked with the win32 thread of clicking the listbox triggering the event handler code.

Originally Posted by matsp

You are aware, I suppose, that MFC is not supposed to be used in multiple threads?

--
Mats

thanks. that pointed to me in the right direction. i was using boost::thread to do my reading data thread, and it appears i should be using MFC specific thread creation functions.

Does the problem have anything to do with the fact that you aquire a lock in a function, then call another function that tries to get a lock when the previous lock was never released? Seems like that would cause deadlocking but I have zero experience with boost libraries.

Originally Posted by valaris

Does the problem have anything to do with the fact that you aquire a lock in a function, then call another function that tries to get a lock when the previous lock was never released? Seems like that would cause deadlocking but I have zero experience with boost libraries.

It is automatically released with the destructor of the lock_guard object

Well still the destructor wouldn't be called in the first function by the time hes waiting on the lock on the 2nd. But I didn't know that a recursive mutex worked as matsp described, so I guess that makes sense.

Originally Posted by valaris

Does the problem have anything to do with the fact that you aquire a lock in a function, then call another function that tries to get a lock when the previous lock was never released?

theoretically speaking the code i've posted cannot deadlock by design. deadlock can only occur if there's a lock A waiting on lock B, and lock B is waiting on lock A. in my scenario, there is only 1 lock, and both segments of code do not wait on anything, thus my scenario *should* be impossible to deadlock.

i haven't gotten around to fixing it yet, but it's likely that i used boost::thread instead of AfxBeginThread like already mentioned.

Originally Posted by Codeplug

You don't need two locks. For example: your thread does a SendMessage() with __mutex acquired. This in turn causes other messages to be dispatched in the main thread - which could then try to acquire __mutex in the main thread. Now the main thread is blocked on __mutex and your thread is blocked waiting on SendMessage() to return. But it can't return until __mutex is released. But __mutex won't be released until SendMessage() returns. Dead.

damn that made my head spin soooo many times...lol...

anyways, to answer your question, the 2 threads blocking are:
1) the RunModalLoop() function from the main dialog, which ends up calling OnListBoxChanged()
2) the boost::thread reading and calling OnListBoxChanged after changing the vector