Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Visual C++/MFC/WTL > Multithreading + MFC

Автор: deniska 30.6.2006, 06:56

Задача такая. Помимо потока GUI необходимо создать еще один, который 10 раз в сек опрашивает железку, и некоторые результаты должен вносить в контролы формы ( несколько Edit, несколько CheckBox, рисование на Bitmapе ). Как такие вещи обычно реализовываются?
( Если по MSDN то это что? user-interface thread или working thread? ), какие параметры нужно передать в функцию потока. структуру из хэндлов? вроде криво как-то. вобщем need help smile

Был бы очень благодарен за маленький кусок кода в котором в отдельном потоке в Edit вставляются числа от Random или ченить в этом роде.

Автор: deniska 30.6.2006, 07:51

ну хоть кто-нибудь, помогите разобраться

Автор: Earnest 30.6.2006, 07:54

Не стОит обращаться к окнам, созданным в другом потоке, чтобы прямо туда что-то записывать. Лучше реализовать так: пусть твой поток опрашивает железку и меняет состояние (заносит данные) в некий объект, независимо от GUI. А GUI на idle опрашивает этот объект и, если были изменения, изменяет значение полей. Конечно, доступ к данным объекта нужно защитить хотя бы critical section.
Я недавно в одной из тем приводила код пары простых классов, реализующих синхронизацию on-idle. Поищи слово CStampTracker.
Опрос on-idle можно делать, в зависимости от типа окна, на WM_IDLEUPDATECMDUI (для немодальных окон) или на WM_KICKIDLE (для модальных).
Примерно так:

Код


// класс, в котором храняться данные (см. тему с кодом CStampTracker)
// к объекту этого класса должен иметь доступ поток и GUI
class CMyData: public CStampHolder 
{
public:
   int getData() const
   {
       CSingleLock _lock(&m_cs,TRUE);
       return m_data;
   }
   void setData(int data)
   {
       CSingleLock _lock(&m_cs,TRUE);
       m_data = data;
       Modified();
   }

private:
   int m_data;
   mutable CCriticalSection m_cs;
}; 

// окно в главном потоке
class CMyWindow: public CDialog  
{
public:
   ...
   afx_msg void OnIdleUpdate()
   {
      if (m_Tracker.EnsureSync (*m_pData))
      {
          CString str;
          str.Format (_T("%d"), m_pData->getData());
          m_edit.SetWindowText(str);
      }
   }

private:
   CStampTracker m_tracker;
   CEdit m_edit;
   CMyData* m_pData;
};

BEGIN_MESSAGE_MAP(...)
   // или WM_KICKIDLE, если окно модальное
   ON_MESSAGE_VOID (WM_IDLEUPDATECMDUI, OnIdleUpdate)
END_MESSAGE_MAP()

Автор: deniska 30.6.2006, 08:01

Цитата

Конечно, доступ к данным объекта нужно защитить хотя бы critical section.

А зачем? я всегда думал что если один поток ТОЛЬКО записывает данные в некую структуру например, а второй ТОЛЬКО считывает их оттуда, то синхронизация не нужна. Я не прав?

Автор: takedo 30.6.2006, 08:04

По моему обработка в OnIddle излишня. Можно просто менять данные и после этого посылать сообщение. При этом синхронизировать нужно только обращение к данным. smile

Добавлено @ 08:05
deniska, ты не прав

Добавлено @ 08:06
потоки считай выполняются параллельно(это не так, но в общем предполагать нужно именно так). Если один поток начал писать данные(5 бит), а второй их в этот момент считывает, что получит второй? - ерудну

Автор: takedo 30.6.2006, 08:25

Earnest, прошу прощения, но "mutable CCriticalSection m_cs;" - что значит mutable?

Автор: Earnest 30.6.2006, 08:35

Цитата(deniska @ 30.6.2006, 09:01

)

А зачем? я всегда думал что если один поток ТОЛЬКО записывает данные в некую структуру например, а второй ТОЛЬКО считывает их оттуда, то синхронизация не нужна.

Takedo, в общем, правильно сказал. Только насчет 5 бит погорячился. Все-таки существует некоторая атомарность. Если речь идет об интах, то можно обойтись функциями Interlocked... Но я ведь просто пример привела - данные обычно более сложные.

Цитата(takedo @ 30.6.2006, 09:04

)

По моему обработка в OnIddle излишня

Нет, она позволяет избавить поток, опрашивающий железку, от ненужных связей и зависимостей. Кроме того, а что если слушателей будет больше, т.е. за данными нужно следать 2 и более окнам или другим объектам? Описанный механизм синхронизации позволяет это сделать, не внося изменений в основной код.

Цитата(takedo @ 30.6.2006, 09:25

)

что значит mutable

Ну, takedo, не ожидала от тебя такого вопроса. smile

mutable позволяет изменять переменную в не-константных функциях. См. getData: CSingleLock хочет неконстантную ссылку, а функция - константная.

Автор: takedo 30.6.2006, 08:43

Earnest,

Цитата

- очень разумно. Только иногда можно ведь в OnIddle и вообще не попасть? smile

. Если такое произойдет(это я для тебя )
deniska, стараюсь smile

) можно поставить в каждом окне таймер и по нему вести обновление. Вообщем решать тебе. вот можешь тут посмотреть, глядишь поможет чем http://forum.vingrad.ru/index.php?showtopic=100331. И поищи по форму - тут оказывается в факе можно на интересные вещи наткнуться smile

Добавлено @ 08:48

Цитата

Ну, takedo, не ожидала от тебя такого вопроса.

не сердись, я же подписываюсь: "я не гольфист - я хоккеист" smile

Автор: deniska 30.6.2006, 09:52

WM_IDLEUPDATECMDUI undeclared identifier.
MSDN - тишина.
че это за зверь такой? какое-то свое сообщение? как его обработать в dialog-based приложении

Автор: SergeCpp 30.6.2006, 10:33

WM_IDLEUPDATECMDUI

В MSDN по поиску находится несколько ссылок...

AFXPRIV.H
#define WM_IDLEUPDATECMDUI 0x0363 // wParam == bDisableIfNoHandler

Автор: Earnest 30.6.2006, 11:35

Да, это сообщение определено в afxpriv.h, также как макрос ON_MESSAGE_VOID.
Сообщение рассылается всем окнам при вхождении в холостой цикл.

Цитата(takedo @ 30.6.2006, 09:43

)

Только иногда можно ведь в OnIddle и вообще не попасть?

Если все делать правильно - нельзя! smile

Idle-сообщение приходит железно.
Пользуюсь обновлением и синхронизацией on-idle несколько лет - метод ни разу не подводил. Конечно, это не панацея от всех случаев - иногда нужна синхронная обработка.
Но если достаточно асинхронной (90% случаев), то это - самый лучший метод: не порождает лишних зависимостей, практически бесплатный, позволяет подключить любое число подписчиков, а уж простой-то - дальше некуда.

Автор: DeadSoul 1.7.2006, 09:56

Цитата(deniska @ 30.6.2006, 08:01

)

Цитата
Конечно, доступ к данным объекта нужно защитить хотя бы critical section.
А зачем? я всегда думал что если один поток ТОЛЬКО записывает данные в некую структуру например, а второй ТОЛЬКО считывает их оттуда, то синхронизация не нужна. Я не прав?

Это неверно. Представь, что у тебя данные = две интовые переменные. При такой последовательности действий:
- writer изменил первую переменную
- стал активным поток reader(writer не успел изменить вторую переменную)
- reader отобразил(на диалог\консоль) эти две переменнные. Это может не являтся валидной парой переменных

Автор: deniska 3.7.2006, 09:00

Вобщем народ спасибо всем кто откликнулся. Оцените:
В потоке GUI по нажатию на кнопку запускается мильтимедийный таймер (собственно второй поток).
каждый раз после выполнения определенных действий этот поток обновляет значения в определенной структуре, после чего посылает GUI PostMessage какой-нибудь WM_USER+1, и GUI поток по этому сообщению считывает значения из структуры и обновляет контролы. Обращения к структуре все в CriticalSection.
На сколько кривой способ?

Автор: takedo 3.7.2006, 09:43

нинасколько

Добавлено @ 09:45
да, тлоько вот можешь ещё попробовать как Earnest, тогда не надо слать сообщение.