Насос сообщений Windows - PullRequest
Новая
       37

Насос сообщений Windows

2 голосов
/ 14 февраля 2011

Это просто технический вопрос для улучшения моего понимания архитектуры ОС.

Я понимаю, что при выполнении метода Application.Run () создается новая форма с насосом сообщений. Из MSDN и других онлайн-статей я понимаю его многопоточность и даже понимаю, что компоненты ОС Windows, такие как уровень HAL, службы ядра ОС и приложения на вершине иерархии, также обмениваются данными друг с другом с помощью обмена сообщениями.

Это только для Windows или в среде Linux?

Можно ли считать это семафором? Или определение и контекст семафора имеют смысл только в многопоточной среде?

Пожалуйста, совет.

Спасибо

Subbu

Ответы [ 2 ]

0 голосов
/ 01 февраля 2015

Системы Unix имеют очереди сообщений: 

#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/msg.h>

int msgsnd(int msqid, const void *msgp, size_t msgsz, int msgflg);
ssize_t msgrcv(int msqid, void *msgp, size_t msgsz, long msgtyp, int msgflg);

, которые используются гораздо реже, чем сообщения Windows, но работают очень похожим образом. Также очень похожая концепция, язык Go прекрасно реализует CSV (, сообщающий последовательные процессы ), который является превосходной многозадачной парадигмой, потому что не страдает от экспоненциального роста сложности. Я бы порекомендовал системным программистам Unix больше использовать очереди сообщений.

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

Относительно семафоров

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

0 голосов
/ 16 июня 2011

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

Что касается семафоров: я не уверен, как они должны быть связаны с передачей сообщений, объектами семафоров, разработаннымидля разрешения программистам создавать критические разделы кода.Поскольку в UNIX семафоры могут совместно использоваться даже разными процессами (не только разными потоками в одном процессе), они имеют смысл в любой многопроцессорной ОС (почти во всех современных ОС), даже без поддержки потоков.

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

...