Обновление CListViewCtrl из рабочих потоков в WTL и C++

Question

Как и в заголовке, я хочу добавить/удалить элементы класса, полученного из класса WTL CListViewCtrl, из рабочих потоков, но всегда получаю «Необработанное исключение: нарушение прав доступа к чтению».

Я попытался Win32 API PostMessage и SendMessage но когда рабочий поток коснется HWND из CListViewCtrl я получаю такое же исключение.

// CListCtrl member function, calling from worker thread 
HWND GetHwnd() 
{ 
    return hwndListCtrl;  // exception here 
} 

Я это SafeQueue, но когда рабочий поток затрагивает мьютекс или очередь, то исключение попробовал еще раз.

// SafeQueue is member variable in CListViewCtrl, created in GUI thread 
SafeQueue<T> m_SafeQueue; 
. . . 
// member function in SafeQueue class, calling from worker thread 
void enqueue(T t) 
{ 
    std::lock_guard<std::mutex> lock(m); // exception here 
    q->push(t); 
} 

Я попытался создать мьютекс и очередь с новый и HeapAlloc/LocalAlloc но тем же исключением снова.

Я пробовал Win32 API CreateMutex, но не повезло, это же исключение при доступе к дескриптору мьютекса из рабочего потока.

Он отлично работает, когда я добавляю элементы из потока графического интерфейса.

Единственный способ это работает из рабочих потоков, если я объявляю HWND или мьютекс и очередь в статической/глобальной, но я хотел бы избежать этого, так как я хочу использовать более одного экземпляра из этого ListControl и я предпочитаю любой более изящный способ, чем глобальная переменная.

Я хочу сделать этот класс многоразовым, так как я хочу использовать его много раз с несколькими модификациями (больше столбцов, разных цветов).

Я ценю любую помощь и идею, как я могу это сделать.

Окружающая среда: VS2015 сообщество, WTL/C++ и Win10 Pro 64bit

Я нашел проблему, которая вызывает нарушение прав доступа: Я объявил ThreadProc функции обратного вызова в качестве функциистатического члена в классе CListViewCtrl.

// DO NOT USE 
// in CListViewCtrl 
**static** DWORD WINAPI ThreadProc(LPVOID lp) 
{ 
. . . 
} 

LRESULT OnStartWorkerThread(WORD /*wNotifyCode*/, WORD /*wID*/, HWND . ..) 
{ 
    DWORD dw; 
    ::CreateThread(NULL, 0, this->ThreadProc, NULL, 0, &dw); 
} 

рабочий раствор:

class CListViewCtrl ... 
{ 
    // thread-safe queue to store listctrl items to be added later in GUI thread 
    SafeQueue<CListCtrlItem<nCols> > m_SafeQueue; 

    // thread ID of the thread in which listctrl was created, saved in OnCreate 
    DWORD m_dwGuiTid; 

    // . . . 

Проверить, если SafeAddItem функция вызывается из GUI или любых других потоки

BOOL InvokeRequired() 
    { 
     if (m_GuiTid == ::GetCurrentThreadId()) 
      return false; 

     return true; 
    } 

    // ... 

SafeAddItem функции-члена может быть вызвана из графического интерфейса и рабочего нити

void SafeAddItem(CListCtrlItem<nCols> item) 
    { 
     if (!InvokeRequired()) 
     { 
      // we are in GUI thread so just add listctrl item "normal" way 
      AddItem(item); 
      return; 
     } 

    // we are in other thread so enqueue listctrl item and post a message to GUI   
     m_SafeQueue.Enqueue(item); 
     ::PostMessage(m_hWnd, WM_ADD_ITEM, 0, 0); 
    } 
    // . . . 

Обработчик сообщений из PostMessage, мы в GUI потоке

LRESULT OnAddItem(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM lParam, BOOL& bHandled) 
    { 
     CListCtrlItem<nCols> item; 
     while (!m_SafeQueue.Empty()) 
     { 
      item = m_SafeQueue.Dequeue(); 
      // we are in GUI thread so we can add list ctrl items normal way 
      AddItem(item); 
     } 
     return 1; 
    } 
    // ... 
} 

И теперь мы можем добавлять элементы ListCtrl из любых потоков таким образом.Я прохожу этот указатель ThreadProc в _beginthreadex

m_ListCtrl.SafeAddItem(item); 

Answer 1

В Windows вы никогда не должны непосредственно изменять элемент управления GUI с помощью рабочего потока. В мире .NET, если мы хотим обновить элемент управления через рабочий поток, мы должны вызвать платформу на делетете, которая в основном выполняет контекстный переключатель.

У вас аналогичная проблема в WIN32.

Существует прекрасная статья на эту тему, на которую я обращу ваше внимание. В нем также рассматриваются различные безопасные обходные пути: https://www.codeproject.com/Articles/552/Using-Worker-Threads

рабочих потоков и GUI II:.. Не касайтесь графического интерфейса пользователя

«Это право Рабочий поток не должен касаться объекта GUI Это означает, что вы не должны запроса состояния элемента управления, добавить что-то в окно списка, установить состояние управления и т.д.

Почему?

Потому что вы можете попасть в серьезную тупиковой ситуации. классический пример был размещен на один дискуссионных советов, и он описал что-то, что произошло с я в прошлом году. Ситуация такова: вы начинаете поток, а затем решаете дождаться завершения потока. Тем временем поток делает что-то явно безобидное, например, добавляет что-то в поле списка, или, в примере, который был отправлен, вызывает FindWindow. В обоих случаях процесс пришел в ступор, так как зашли в тупик все нити.»

Answer 2

вопрос, как представляется, на самом деле не о UI обновлений от рабочего потока, но и о правильном использовании рабочих потоков сами по себе.

Существует достаточное количество комментариев об опасностях, связанных с обновлением пользовательского интерфейса: все они связаны с потенциальной проблемой взаимоблокировки. Большинство обновлений связано с отправкой сообщения, которое является вызовом API блокировки. Пока вы выполняете обновление из рабочего потока и вызывающего потока заблокирован, любая попытка обработчика в пользовательском интерфейсе для синхронизации или совместной работы с рабочим может привести к тупиковой ситуации. Единственный способ обойти это - подготовить обновление в рабочем потоке и передать поток пользовательского интерфейса (в том числе путем размещения сообщения вместо этого его отправки, i n условий SendMessage, PostMessage API), чтобы взять и завершить обновления из потока пользовательского интерфейса.

К оригинальной проблеме: у вас, похоже, проблема со статической процедурой потока. The fourth argument in the CreateThread call is:

lpParameter [в, по выбору]

указатель на переменную, которые должны быть переданы нити.

У вас есть это NULL и вы, как правило, использовать его, чтобы передать this значение для вашей процедуры нить обратного вызова. Таким образом, вы можете передать исполнение назад от статической функции к экземпляру класса:

DWORD CFoo::ThreadProc() 
{ 
    // ThreadProc with proper "this" initialization 
    // HWND h = GetHwnd()... 
} 
DWORD WINAPI ThreadProc(LPVOID pvParameter) 
{ 
    return ((CFoo*) pvParameter)->ThreadProc(); 
} 
LRESULT CFoo::OnStartWorkerThread(WORD /*wNotifyCode*/, WORD /*wID*/, HWND ...) 
{ 
    DWORD dw; 
    ::CreateThread(NULL, 0, this->ThreadProc, (LPVOID) this, 0, &dw); 
} 

Также обратите внимание, что вы не должны использовать CreateThread прямо: у вас есть _beginthreadex и AtlCreateThread (related question).