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.

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

--
Mats

Quote:

---

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.

To clarify - if you use any part of MFC in an additional thread, then that thread should be created using AfxBeginThread to ensure that the thread plays nicely within the framework. Also, you typically don't touch MFC UI objects from multiple thread - which is what I believe matsp was referring to.

I would guess that your "deadlock" is probably due to calls to SendMessage() within your thread that are occurring "under the hood" of MFC. In the end, you'll want to keep UI stuff all within the main thread of the app and let any extra threads just do processing. You can post custom messages from your thread(s) if UI state needs to be "refreshed" or changed.

gg

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.

Quote:

---

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 a "recursive mutex", so assuming that it does what is says on the label, it should allow the same thread to lock multiple times and only allow another thread in once all locks of the first thread have been released - of course care has to be taken that the lock is released exactly the same number of times that it was taken - otherwise problems with occur.

--
Mats

Quote:

---

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.

Quote:

---

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.

Quote:

---

Originally Posted by bling

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.

---

Yes, but MFC internal functions definitely have their own locks, so if for some reason you call the function that requires YOUR lock from a function that holds the internal lock and at the same time your other thread wants to get hold of the MFC lock, it will go wrong.

--
Mats

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.

Run the code in the debugger. Reproduce the deadlock. Examine the call stack of the main thread and your thread and see exactly where/what they are blocking on.

gg

Quote:

---

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

So they are both in OnListBoxChanged() - but where exactly?
lock constructor, GetCurSel, SetWindowText, or lock destructor?

If you comment out GetCurSel and SetWindowText does the deadlock still occur (in the same place).

gg

let's see....with my OnListBoxChanged() handling consisting of only constructing a lock (GetCurSel and SetWindowText and commented out), it deadlocks at:
1) CListBox::AddString from the read thread which is now created with AfxBeginThread
2) OnListBoxChanged with the final call at boost's win32::WaitForSingleObject

i'm thinking it's because i'm still calling AddString() in the read thread, which is a worker thread, not GUI thread. i was wondering why MFC doesn't throw exceptions all over the place like C# does if you don't use (Begin)Invoke(), but i think i know why now....it's got the same problems but doesn't let you know until later on when you've already written all the code!!

yep, the problem was AddString.

thanks for all the help guys. now i know a little more about the nuances of MFC :P

You probably would have the same issues if it were using just the Win32 API - due to the SendMessage() scenario I described earlier.
This is all CListBox::AddString() does:

Code:

---

_AFXWIN_INLINE int CListBox::AddString(LPCTSTR lpszItem)
        { ASSERT(::IsWindow(m_hWnd)); return (int)::SendMessage(m_hWnd, LB_ADDSTRING, 0, (LPARAM)lpszItem); }

---

The lesson to take away from this is: "keep UI in the main UI thread".

gg