Олег Цилюрик - QNX/UNIX - Анатомия параллелизма

CPU speed [c.p.s ]: client = 534639500, server = 451163200

manager exchange: number = 3102, stream = 0.0557978 Mbit/sec

# clr -nrtp -b100

SRR repeater: vers. 1.03

server path: /net/rtp/dev/srr, block size = 100 bytes

CPU speed [c.p.s.]: client = 534639500, server = 451163200

message exchange: number = 3347, stream = 0.507917 Mbit/sec

При взаимодействии клиента с сервером по сети в тех же условиях, что и на рис. 5.2, клиент уже не загружает процессор более чем на 50% (рис. 5.3). Если организовать обмен клиента с сервером в несколько потоков (2-3), то при максимальной загрузке процессора можно увеличить плотность потока еще вдвое.

Рис. 5.3. Загрузка процессора клиента при сетевом взаимодействии клиента с сервером

# clr -nrtp -b100 -d

SRR repeater: vers. 1.03

server path: /net/rtp/dev/srr, block size = 100 bytes

CPU speed [c.p.s.]: client = 534639500, server = 451163200

manager exchange: number = 2167; stream = 0.480264 Mbit/sec

# clr -nrtp -b1000

SRR repeater: vers. 1.03

server path: /net/rtp/dev/srr, block size = 1000 bytes

CPU speed [c.p.s.]: client = 534639500, server = 451163200

message exchange: number = 1400; stream = 2.0555 Mbit/sec

# clr -nrtp -b1000 -d

SRR repeater: vers. 1.03

server path: /net/rtp/dev/srr, block size = 1000 bytes

CPU speed [c.p.s.]: client = 534639500, server = 451163200

manager exchange: number = 1626; stream = 2.00553 Mbit/sec

# clr -nrtp -b10000

SRR repeater: vers. 1.03

server path: /net/rtp/dev/srr, block size = 10000 bytes

CPU speed [c.p.s.]: client = 534639500, server = 451163200

message exchange: number = 366; stream = 4.73793 Mbit/sec

# clr -nrtp -b10000 -d

SRR repeater: vers 1.03

server path: /net/rtp/dev/srr, block size = 10000 bytes

CPU speed [c.p.s.]: client = 534639500, server = 451163200

manager exchange: number = 440; stream = 4.39515 Mbit/sec

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

Обратите внимание, что при больших блоках передаваемых данных (10 Кбайт) скорость информационного канала (4.395–4.738*2, учитывая что ретрансляция ведется в двух направлениях) сильно приближается к физической пропускной способности канала (10 Мбит/сек, как уже отмечалось выше), что попутно говорит о весьма высокой эффективности реализации обмена протоколами сети QNET.

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

Два альтернативных пути не являются «взаимоисключающими», хотя это и реализации единого базового механизма. Они настолько далеко «разошлись» друг от друга, что приобрели индивидуальные, не воспроизводимые альтернативным способом черты. Более того, они могут кооперироваться в рамках даже одного процесса, как это было сделано в показанном ранее примере. Принятию того или иного решения должен предшествовать детальный анализ требований решаемой задачи.

Обмен сообщениями (message passing) является основой архитектуры ОС QNX, на которой строится значительная часть служебных функций системы. Несмотря на свою «элементарность», он является удобным (и в силу своей «нативности» чрезвычайно эффективным!) механизмом для непосредственной организации взаимодействия между процессами. Особый же шарм этого механизма заключается в том, что вместе с передачей данных как таковой можно естественным образом (на основе блокировок Send/Receive/Reply) организовать синхронизацию взаимодействующих процессов.

И хотя в QNX 6 появилось такое мощное средство для организации обмена данными, как менеджер ресурсов, а также имеется богатый набор средств синхронизации, способный удовлетворить любого программиста, имеющего опыт работы в POSIX-совместимых системах, механизм обмена сообщениями по-прежнему остается привлекательным средством, используемым непосредственно в разработке ПО. Особенно отчетливо это проявляется в среде разработчиков, мигрирующих с предыдущих версий ОС QNX, и вряд ли может быть объяснено только их, программистов, консерватизмом.