А вот интересно...

[Malckhazar]

... господа программисты, а кто-нить когда-нить писал свои потоки передачи данных (те, что streams, а не threads)?

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

Вариант 1, стандартный: создаем классы-преобразователи, которые некоторым образом преобразовывают данные и работают в жесткой цепочке, четко зная, кому надо что передать. Минусы варианта очевидны: нет гибкости в передаче, а иной раз реализация может превратиться в жуткий кошмар (у меня есть пример проекта, где сначала строится жесткая цепочка из таких классов путем передачи callback-ов, по которым затем передаются данные на обработку), да и в случае многопотокового приложения синхронизация этого дела представляет отдельный кошмар. Плюс - подход далеко не новый и довольно хорошо известный.

Вариант 2, вчера придуманный: Весь процесс передачи информации вместе с преобразованием данных можно представить как поток от источника до приемника. Особенно это актуально для случая, когда источники и приемники работают в разных нитях (threads). Процесс передачи данных можно реализовать стандартным потоком (через pipe), внутри которого, кроме всего прочего, можно сделать применение некоторой операции преобразования. Это решает еще и часть задачи синхронизации данных: поток является кольцевым буфером, запрещающим перезапись данных (записанные данные _должны_ быть прочитаны, чтобы освободить буфер). Надо бы подумать над этим вопросом...

UPD: Вариант с пайпами, кстати, еще и легче реализуется как кроссплатформенный, ибо pipe это POSIX и сидит в std, а совсем не "M$-specific".

PS: Да, что-то с утра голова не оч хорошо работает... гудит немного и болит чуток :/

@темы: программистское

Comments

[Alarik]

А если клиент-сервер и через сокеты? Там обычно вопросы синхронизации разруливаются особенно красиво, на Java или Python'е...

[Malckhazar]

Я рассматриваю решение задачи исключительно в пределах C++ ввиду того, что это мой основной язык программирования.

[Melnax]

На словосочетании "ногопотоковое приложение" мысль у меня сбилась и извращенное воображение нарисовало картину внезапно сломавшегося экалатора в час пик. О.о

[Alarik]

С++ вроде тоже сокеты по-всякому умеет, хоть и без элегантной синхронизации, нэ?
Или это вообще мёртвый язык, на манер латыни?

Слово "streams" у меня упорно ассоциируется с потоковыми UNIX-сокетами, тем более, что именно с их помощью я небезуспешно пытался реализовать последнюю свою программулину. Способов межпроцессного взаимодействия много, и сокеты - один из них.

[Malckhazar]

Melnax, бгггг! Исправил

Alarik_la_Elf, а мне не нужно реализовывать это вне одного процесса. Это задача об эффективной передаче данных и синхронизации потоков в приложении.
С++ ни разу не мертв, он продолжает совершенствоваться до сих пор, если судить об огромной поддержке этого языка и по совершенствующимся стандартам.

Есть такая замечательная штука как операторы потокового ввода/вывода, пример реализации - cin/cout в namespace std. Вот это и есть стрим. Типичный до зубовного скрежета.

[Alarik]

Хм, начинаю соображать. Да, сокеты в рамках одного приложения это странно, даже при множестве нитей, согласен. Но что ты имеешь ввиду под применением некоторой операции преобразования внутри трубки? Причём в обход классов-преобразователей на входе и выходе из трубки...

[Malckhazar]

Ну, насчет pipe я узнал некоторую неприятнейшую особенность: пайпы (я предпочитаю называть их именно так) работают на уровне ядра, причем порождая еще как минимум один поток (для самого же пайпа). Пайп хорош только для соединения между процессами, увы!

А вообще имелось ввиду следующее: Представь цепочку инф-ии:
источник -> преобразователь -> приемник

Я же предлагаю тут сделать вот так:
источник -> приемник
, причем "преобразователь" прячется внутри стрелочки с одной из сторон (либо на источнике, либо на приемнике - зависит, где критичнее время). Да, фактически, ничего не произошло - преобразование только спряталось внутрь класса, отвечающего за передачу данных между потоками - но! - в контексте информационного потока эта операция исчезает как и специализированная сущность.

[Alarik]

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

[Malckhazar]

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