Здравствуйте, sjukov, Вы писали:

S>Здравствуйте, Кодт, Вы писали:

К>>Здравствуйте, sjukov, Вы писали:

S>>>Коллеги! посоветуйте пожалуйста как лучше всего сделать связь между
S>>>несколькими потоками одного процесса? я знаю что есть
S>>>1. именованные каналы

К>>можно и безымянные. В пределах одного процесса-то...

S>>>2. мэйл слоты
S>>>3. message (wm_copydata)
S>>>и т.д..
S>>>но как-то это все никузяво....

S>>>Мне надо по сути уведомлять один из потоков о сыбытиях в других потоках и в ответ на это событие
S>>>отсылать команды обратно — "указания" что нужно делать дальше.

К>>А какого рода указания?
S>Рабочий поток постоянно читает что-то с com-порта(at команды gsm модема — на факт наличия входщих непрочитанных СМС). При считывания валидной строки с порта ,поток отсылает уведомление в главный поток приложения... приложение должно передать прочитанную
S>иформацию в другой поток , который запишет принятое СМС В БД (ms sql) Если все прошло без ошибок, то передается управление опять "читальщику"
S>с ком порта, где уже посылается at команда на удаление принятого СМС. чтобы не засорять память.

S>По идее лучше это сделать в виде "разделямых данных". т.к. важно чтобы смс удалялось только в том случае когда
S>запись окажется в БД(система дистанционного управления городского освещения(когда из автоматического режима нужно перейти в ручной для
S>управления с главного ПК)) — инофрмация важная

S>,.. хотя возможно я не совсем выкупил фишку с очередями

К>>Насколько асинхронно всё это происходит, могут ли возникать очереди сообщений (кстати, о message queue!) или достаточно рандеву вокруг разделяемых данных?
К>>Распиши сценарии, а потом под это дело придумаем решение.

S>По идее обработка следующего смс не наступит ранее как будет обработано предыдущее — записано в БД и стерто с
S>SIM карты.
Тогда не совсем понятно зачем нужно несколько потоков для решения задачи, какие бонусы?

S>Возможно я не совсем верно продумал "архитектуру", если это так можно назвать