Многопоточьность

Прав ли я?

Нет. //grammar nazi

anonymous

Нет. //grammar nazi

++

чтение и запись разносит в разные потоки

Интересно, и как оно у него работает? Или он взаимные блокировки делает? Ну и нафига тогда 2 потока?

Конечно, прав.

Все зависит от количества портов.

8+

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

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

Ну интерфейс это всегда отдельный поток иначе это будет очень веселая программа.

может в конкретной задаче и можно одним потоком

Да именно такой случай. Зачем делать два, а потом в обоих ставить мониторы для блокировки друг дружки.

Интересно, и как оно у него работает? Или он взаимные блокировки делает? Ну и нафига тогда 2 потока?

Да, это хорошо сказал. Спасибо, есть идея!

программа которая пишет/читает из серийного порта

на 2х ядрах которые не дотягивают до 2ГГц

Многопоточность

мда…

epoll для серийных портов недоступен?

Учитывая максимальную скорость серийного порта, разницы никакой не будет, хоть по десять потоков на канал делай.

Ну ладно, на примере, тогда . Поток ушел на чтение, а ответа нет, что делать ?

Поток ушел на чтение, а ответа нет, что делать?

Матюкаться. Т.к. выйдет таймаут select'а.

У меня там select...

С определенным тайм-аутом...

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

События отправки и чтения чередуются и логически между собой связаны.

К примеру подтверждение получения, откуда следует, что отправлять дальше...

Да это понятно всё, что связаны.

В случае двух потоков.
Чтение - висит в ожидании «прихода». Байт(ы) пришли , заблокировал буфер, записал в конец, разблокировал буфер, снова завис на чтении.

Запись - передал, завис на тайм-аут , заблокировал буфер, прочитал, разблокировал буфер, проанализировал прочитанное, сделал новую передачу.

В случае одного потока все функции помещаются в один, только перед ними еще и анализ почему поток начал возобновился.

Разницы особой нет, может и погорячился что нельзя в один.
Но пробовал так и так , с двумя показалось проще. Тем более это часто уходит на железку без ОС. Поток чтения вешается на прерывание, он быстрый, поток записи вызывается в главном цикле с задержкой, переделки кода практически нет. А в случае с select надо делать заново.

В самом названии USART подразумевается асинхронность - т.е. независимость друг от друга потоков входной и выходной информации. Т.о., если подключенный к COM-порту узел выполняет асинхронный и достаточно интенсивный обмен данными, то при использовании только одного потока осуществить полноценное с ним общение, вероятно, будет сделать несколько сложнее, ибо в нем можно либо читать, либо писать - отсюда в процессе обработки и записи данных в COM-порт связанный с дескриптором порта входной буфер ОС теоретически может быть переполнен и возникнуть потеря входных данных.

Самая ресурсоемкая операция - создание потока. С переключением все намного проще.

Спасибо! И вам ilovewindows тоже.

твои аргументы очень даже верны, но только для общего случая. в случае же

Многопоточность (комментарий)

ситуации

в процессе обработки и записи данных в COM-порт связанный с дескриптором порта входной буфер ОС теоретически может быть переполнен и возникнуть потеря входных данных.

никогда не возникнет. ну, разве что у програмера руки совсем уж кривые.

Вопрос возможно глупы но:

К одному дескриптору можно в один момент времени read и write из разных процессов применять?

полагаю, что да. но я точно не знаю. я бы так не делал, я стороник реализации этой задачи с poll/select.