LINUX.ORG.RU

[клиент-сервер] архитектура программы


0

0

Стоит задача управления несколькими девайсинами. Централизованное приложение по сети передает пакеты с заданиями для каждого из этих устройств моему серверу. Тот должен в соответствии с той или иной командой выполнить кое-какие расчеты и, в конце-концов, переслать данные по последовательному порту собственно адресату.

Пока что на ум пришло выделять отдельный поток для каждого из этих устройств и в нем производить вычисления / организовывать связь по ttyS*. Сразу же за этим появляется вопрос по поводу передачи управляющих данных в отдельные треды. Это надо как-то в главном цикле программы обрабатывать приходящие данные, определять идентификатор устройства и уже потом давать знать соответствующему потоку, что он может забрать посылочку? Если так, что что лучше использовать для передачи информации потоку? пайп, юникс сокет?


>Если так, что что лучше использовать для передачи информации потоку?

Простой вызов функции не пойдет?

winlogon ()
Ответ на: комментарий от winlogon

а как это будет выглядеть? ..я что-то не совсем представляю

Corey ()

>> пайп, юникс сокет?

Сам все знаешь )) Пайп проще, ИМХО.

cathode ()

> что лучше использовать для передачи информации потоку?

Ничего не использовать. Передавать как есть, только не забывать лочить в нужных местах.

LamerOk ★★★★★ ()
Ответ на: комментарий от LamerOk

>> что лучше использовать для передачи информации потоку?

Ничего не использовать. Передавать как есть, только не забывать лочить в нужных местах.


то есть просто разделять память входного буфера с данными, а каким-нибудь флагом указывать, что данные для потока готовы? А не будет ли бесконечная проверка этого флага в цикле потока неэффективной тратой процессорного времени?

Я почему подумал про пайп, что вызов read просто заблокирует тред до нужного момента, и он не будет давать системе никакой нагрузки. Или есть какой-то другой метод?

Corey ()

С FIFO придется вводить кучу блокировок и всяких семафоров, что может грозить задержками. Можно использовать разделяемую память или отобразить память в файл, но если будут писать несколько приложений, опять-таки, могут быть задержки. Выбирать вам, исходя из нагрузки. А насчет протокола управления железяками, советую не использовать устаревший RS-232 - переходите на CAN, в конце-концов. А еще лучше - вообще на ethernet, если контроллеры поддерживают. Кстати, у меня есть один знакомый, который на PIC-контроллере с 16Кб оперативки реализовал протокол TCP/IP :) Но я, позор мне, пока использую RS-232 (правда, постепенно перехожу на CAN).

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Corey

А не будет ли бесконечная проверка этого флага в цикле потока неэффективной тратой процессорного времени?

info libc на тему condition variable.

Begemoth ★★★★★ ()
Ответ на: комментарий от Eddy_Em

> Кстати, у меня есть один знакомый, который на PIC-контроллере с 16Кб оперативки реализовал протокол TCP/IP

Теперь у тебя есть шанс на другом PIC-контроллере организовать ping of death в 8 килобайтах :-)

no-dashi ★★★★★ ()
Ответ на: комментарий от Begemoth

да, с сокетами и каналами — это больше по части межпроцессного взаимодействия. Освежил сейчас в памяти программирование с pthreads. Семафоры и CV — то, что нужно.

Corey ()
Ответ на: комментарий от Corey

> А не будет ли бесконечная проверка этого флага в цикле потока неэффективной тратой процессорного времени?

Будет.

Или есть какой-то другой метод?


Конечно есть, иначе какой был бы смысл в потоках?

LamerOk ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.