Обмен сообщениями между классами

[baldr]

Что-то у меня путаница с сообщениями...
Вот объясните - обмениваться сообщениями могут любые классы или только оконные?
Если любые - то как мне послать асинхронное сообщение от одного класса другому?

[Алексей++]

сообщениями WINDOWS - только оконные (от CWnd)

а какие ты имеешь в виду сообщения?

[Finch]

baldr, Если твои классы будут сидеть в разных потоках, то это имеет смысл. А если в одном потоке, тогда я не вижу смысла. Легче делать прямой вызов.
Для разных потоков нужно организовать буффер сообшений. Каждый поток опрашивает этот буфер. Если для класса в потоке есть сообшение, оно отрабатывается, иначе происходит засыпание до следуешего раза.

[baldr]

У меня отрабатывается вызов таймера. Таймер высокочастотный (от 200 герц и выше). При каждом тике мне надо передавать данные другому классу, который будет их записывать или делать что-то еще. Но если делать прямой вызов функции, то обработчик таймера будет ждать возврата. Я хочу, чтобы обработчик быстро кинул куда-нибудь данные и работал дальше.
Как это сделать? Данные должны обрабатываться примерно в то же время, как и поступают.

[baldr]

Как вариант для сообщений: можно отнаследовать оба класса от CCmdTarget. тогда будут доступны сообщения...
Но как в таком случае обмениваться сообщениями? У меня опыта с ними никакого.

[Finch]

baldr, Посади их на разные потоки. Сделай чтобы сразу два класса видели область данных. В области данных сделай переменную-флаг, если флаг поднят, то данные изменены, и требуют записи. Если отпушен, то в области старые данные. Теперь поток таймера изменяет данные и поднимает флаг. поток обработки отрабатывает данные и отпускает флаг. Здесь есть одно но. Отработка данных должна происходить быстрее, чем вызов таймера. Иначе возможно потеря данных. Конечно можно делать буферезацию, но там тоже возможно переполнение.

[baldr]

Finch, я боялся, что кто-нибудь и предложит такой вариант.  
Нет. Это совершенно недопустимо.
Чем хороша очередь сообщений - это асинхронностью обработки.
Буфер:
а) может переполниться.
б) вообще неправильно с точки зрения OOD делать такой общий доступ к одним и тем же данным.
Уж лучше я буду напрямую вызывать функцию, чем буду делать буфер.
Тем более, что читать из буфера, как ты предлагаешь, надо еще с одним таким же таймером.  :new_shot:  Это ж надо будет их синхронизировать, да сколько ресурсов они обабудут жрать??  :new_shot:  :new_shot:

[Finch]

baldr, Вообше то чисто теоретически очередь сообшений и есть буфер.
И поток делает постоянный опрос этого буфера. Как только пришло сообшение, идет его обработка, в противном случае поток засыпает. О возобновлении работы потока заботится Виндовс сам. И тут не нужно ставить ни таймер и ни отдавать кучу ресурсов. У тебя чуть не тревиальная задача и "правильные решения" могут не работать.
Сделай свои данные закрытыми в одном хэдэрэ и их кроме тебя никто видеть и не будет.

[Алексей++]

baldr, коли ты юзишь таймер...
 (да ещё и совершенно не высокочастотный - самый завалящий проц, скажем 300MГц , сумеет за один тик частотой 200Гц сделать 1500000 операций.)
... коли ты используешь таймер - значит операции у тебя синхронные - как же ещё? Если представить один тик в виде отрезка, то в начале каждого начинается очередная операция обработки - например получение данных, обработка, начало_нового_измерения_или_что_там_у_тебя_происходит , или вообще простой, в течение которого можно фоновые операции выполнять.
А если несинхронизированные операции - тогда зачем таймер? Правильно Финч говорит - выполнил одну операцию, приступай к ожиланию/выполнению следующей, а если проц не способен переварить за это время - будет потеря данных или тормоз времени

[Serega]

Бери обычную очередь (мне std:deque нравится)
синхронизировать можно с помощью Readers-Writers Lock или просто мутекс и выгребать сразу всю очередь на обработку (у тебя наверно какраз так)

to Алексей1153, не все так просто, система многозадачная и когда она вдруг решит переключить процесс не известно
Если таймер нормальный (а не WM_TIMER) то он будет срабатывать с приемлемым запаздыванием, а вот что для обработки система даст достаточно процесорного времени это не факт
любая не примитавная обработка включает в себя работу с устройствами или каналами передачи или хранения данных, а это самое время для переключения процессов, т.к. обычно это происходит асинхронно

[Алексей++]

Serega, насчёт загрузки системы - ну так предполагается, что если машина предназначена для сверх-точных скоростных вычислений , то она одновременно не должна форматированть винты ещё пяти компов, соединённых по сети

вот я сейчас делаю прогу - там прибор принимает из эфира инфу ПОСТОЯННО и скидвает на комп - а я её перевариваю, сохраняю , много обработки и вывожу на экран. Читаю и сохраняю как только приходит, а обрабатываю по таймеру в секунду

[Diletant]

Подобные обработки очень душевно осуществляются с набором очередь  плюс семафор. В отличие от Серегиного варианта с мьютексом можно обрабатывать очередь по частям.