LINUX.ORG.RU

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


0

1

Прав ли я?

Ситуация такова: есть программа которая пишет/читает из серийного порта, я реализовал для каждого серийного порта 1 поток который его обрабатывает, мой коллега чтение и запись разносит в разные потоки. Я хочу доказать, что мой вариант архитектуры лучше, обе программы выполняют свои задачи. Мотивация коллеги скорее что-то из старой архитектуры или какой то привычки.

Программа выполняется на 2х ядрах которые не дотягивают до 2ГГц. Это только малая часть продукта но ведь на создание и обслуживание лишних потоков тоже тратится системное время...

Если я прав то как это обосновать так сказать по научному внятно...

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

Прав ли я?

Нет. //grammar nazi

anonymous ()

anonymous

Нет. //grammar nazi

++

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

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

Eddy_Em ☆☆☆☆☆ ()

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

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

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

namezys ★★★★ ()

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

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

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

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

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

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

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

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

LinuxDebian ★★★★ ()

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

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

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

мда…

nanoolinux ★★★★ ()

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

note173 ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ilovewindows ★★★★★ ()

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

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

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

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

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

ситуации

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

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

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

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

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

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