одновременный обмен данными в 2 стороны по 1 сокету
клиент-серверное взаимодействие.
к серверу подрублено несколько клиентов, работающих с общей областью памяти (очередность потоков мьютексами сделана, хотя непринципиально)
при этом при каждом изменении любым из потоков необходимо синхронизировать изменения, т.е. отослать на все клиенты.
возникает вопрос: и клиент и сервер должны постоянно делать recv(..) чтобы не пропустить запросы изменений/ обновления данных.
а как одновременно выполнять send при этом еще?
вариант с 2-мя сокетами на каждого клиента не считаю надежным.
кстати, для оповещения всех потоков указатели на них хранятся в массиве.
есть ли еще какие-то нормальные варианты?
разнеси по разным потокам:
вызваеш в отдельном потоке recv(s1,..)-поток заблокирован пока не получиш данные.
возникла необходимость отправить(в другом потоке) send(s1,..).
кстати, с блокируемыми сокетами так же или нет?
клиент-серверное взаимодействие.
к серверу подрублено несколько клиентов, работающих с общей областью памяти (очередность потоков мьютексами сделана, хотя непринципиально)
при этом при каждом изменении любым из потоков необходимо синхронизировать изменения, т.е. отослать на все клиенты.
возникает вопрос: и клиент и сервер должны постоянно делать recv(..) чтобы не пропустить запросы изменений/ обновления данных.
а как одновременно выполнять send при этом еще?
вариант с 2-мя сокетами на каждого клиента не считаю надежным.
кстати, для оповещения всех потоков указатели на них хранятся в массиве.
есть ли еще какие-то нормальные варианты?
Вариант: последовательно обрабатывать входящие данные клиентов. Т. е. пока не отошлем изменения, вызванные данными одного клиента, данные от других клиентов не принимаем. Это не означает, что сами данные, присланные клиентом, обрабатываются последовательно, иначе от многопотоковой модели ничего не остается :)
Еще вариант. Отдельный поток на отсылку сообщений об обновлении данных. Все потоки отправляют информацию этому потоку, скажем, через канал (pipe).
Кучу вариантов можно придумать, в зависимости от требований к программе.
Примечание. Не нужно бояться создавать потоки. Я как-то ради интереса написал тестовую программулину, оказалось, на создание+уничтожение потока уходит около 80 нс (процессор без гипертрединга, 2,4 ГГц).
Тогда уж просто select )
Тогда уж просто select )
Автор не уточнял ОС, но я сделал вполне определенные выводы по наличию слов "мьютекс" и "поток" в первоначальном посте.
Ну так "мьютекс" и "поток" не прерогатива винды. Более того там они появились как раз позже чем в других ОС.
данная вешь пишется под венду, может быть в нескором будущем портирую(если не заломает то через полгода).
спасибо за советы.
в итоге получается так:
2 потока на каждого клиента:recv'ер с обработчиком пришедщего и send'ер обратно + один на синхронизацию всего.
как только кто-то меняет общие данные, сообщает об этом потоку-синхронизатору через PostThreadMessage. поток-синхронизатор в цикле оповещает все потоки-send'еры.
данная вешь пишется под венду, может быть в нескором будущем портирую(если не заломает то через полгода).
спасибо за советы.
в итоге получается так:
2 потока на каждого клиента:recv'ер с обработчиком пришедщего и send'ер обратно + один на синхронизацию всего.
как только кто-то меняет общие данные, сообщает об этом потоку-синхронизатору через PostThreadMessage. поток-синхронизатор в цикле оповещает все потоки-send'еры.
Да, примерно так. Только я бы рекомендовал вместо PostThreadMessage все-таки использовать, скажем, Event'ы или критические секции, или иные средства синхронизации.
---
P. s. Сейчас подумал над тем, что я написал... Да, у нас ведь будет очередь сообщений, так что действительно лучше PostThreadMessage :)