Работа с com портом

Иди на rsdn.ru спрашивай, тут вам не там

чем не устраивают стандартные и общеизвестные средства синхронизации?

наверное устраивают. Только я с таким вопросом ранее не сталкивался и поэтому общеизвестные мне неизвестные. Ткните носом

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

советую книгу Стивенс UNIX Взаимодействие процессов

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

http://trolltech.com/products/qt/addon/solutions/catalog/4/Utilities/qtshared...

За денюжку.

Если есть сорцы библиотеки, то лучший способ - хак на вызывающиеся функции

гугли по теме qt ipc
думаю, не ты первый

В Boost пишут interprocess. Но когда допишут...

А слона то я и не приметил.

IPC Framework Qt 4.4 will contain an IPC framework, focused on shared memory and system locks. The Shared Memory classes will provide support for creating, attaching, detaching and removing one or more segments of shared memory. System Locks (IPC locks) classes will provide support for creating, acquiring, releasing and destroying a system lock.

Выдели отдельный демон, общающийся с прибором, а остальные проги пусть к нему коннектятся (клиентская чать в либе). Так красивее, имхо. А демон будет уже транслировать данные с прибора.

Стандартная схема, работающая очень давно для модемов и терминалов - это создание лок-файла в известном месте типа /var/lock/... с записью PID процесса в него. Остальные клиенты проверяют наличие лок-файла, читают из него PID и проверяют наличие такого процесса.

Ага. а под оффтопиком?

Программа падает. файл остается. и начинается большой гемморой.

>Программа падает. файл остается. и начинается большой гемморой. читаем внимательней: >и проверяют наличие такого процесса

ты удивишся, но под оффтопиком процессы тоже имеют уникальный ид.

В Qt4 наверно можно dbus использовать, в том числе и под оффтопиком. Заменить библиотеку, которую подгружают программы на обёртку, которая лочит мьютекс/оставляет сообщение в dbus/оставляет lock-файл с PID, и вызывает исходную функцию из библиотеки (когда выгружает библиотеку, обёртка "освобождает ресурс"). См. про RAII, http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization.

Это quick'n'dirty с обёрткой, по нормальному надо делать что-то вроде сервера приложений и программы сделать в нём приложениями-плагинами, или просто оставить их как есть, но сделать типа монитора транзакций, через мьютексы / dbus / PIDы.

maybe можно извратиться с виртуальными компортами. Вот под OS/2 был драйвер виртуального компорта, (и сейчас существуют эмуляторы USB через COM).

И сделать как в plan 9 /dev/console: у каждой программы есть свой виртуальный компорт, с точки зрения программы -- единственный. С точки зрения системы в целом же, /dev/console приложения abc является ссылкой на /prog/abc/dev/console, то есть, виртуальные компорты отображаются в различные реальные.

И "обёртка" - "монитор ресурсов" на самом деле управляет ссылками на нужный виртуальный компорт. Виртуальный компорт работает аналогично реальному, то есть виртуальные компорты мультиплексируются в реальные. А как именно мультиплексируются, определяет монитор ресурсов/транзакций.

итого, придётся писать свой драйвер виртуального компорта, разные реализации для Linux/оффтопика/другого юникса. Драйвер плёвый - обёртка над реальным, и смысл его -- мультиплексировать реальные ресурсы, чтобы со стороны приложения он выглядел как один-единственный виртуальный ресурс. В юниксе, может можно обойтись корректными файловыми ссылками. Под оффтопиком нетривиально ( может, делать ссылки между драйверами в самом корневом пространстве имён, системных объектов. Типа как в виндовом dd путь на устройства в стиле ARC = путь в пространстве имён, //?/C: , а драйвера лежат в //? )

эмуляторы USB через COM -- в смысле, USB-устройство выглядит как виртуальный компорт.