5. Измените листинг 5.4 следующим образом: перед вызовом mq_open напечатайте сообщение и подождите 30 секунд (sleep). После возвращения из mq_open выведите еще одно сообщение и подождите еще 30 секунд, а затем вызовите mq_close. Откомпилируйте программу и запустите ее, указав большое количество сообщений (несколько сотен тысяч) и максимальный размер сообщения, скажем, в 10 байт. Задача заключается в том, чтобы создать большую очередь и проверить, используются ли в реализации отображаемые в память файлы. В течение 30-секундной паузы запустите программу типа ps и посмотрите на занимаемый программой объем памяти. Сделайте это еще раз после возвращения из mq_open. Можете ли вы объяснить происходящее?
6. Что произойдет при вызове memcpy в листинге 5.26, если вызвавший процесс укажет нулевую длину сообщения?
7. Сравните очередь сообщений с двусторонними каналами, описанными в разделе 4.4. Сколько очередей нужно для двусторонней связи между родительским и дочерним процессами?
8. Почему мы не удаляем взаимное исключение и условную переменную в листинге 5.20?
9. Стандарт Posix утверждает, что дескриптор очереди сообщений не может иметь тип массива. Почему?
10. В каком состоянии проводит большую часть времени функция main из листинга 5.12? Что происходит каждый раз при получении сигнала? Как мы обрабатываем эту ситуацию?
11. Не все реализации поддерживают атрибут PTHREAD_PROCESS_SHARED для взаимных исключений и условных переменных. Переделайте реализацию очередей сообщений из раздела 5.8 так, чтобы использовать семафоры Posix (глава 10) вместо взаимных исключений и условных переменных.
12. Расширьте реализацию очередей сообщений Posix из раздела 5.8 так, чтобы она поддерживала SIGEV_THREAD.
Каждой очереди сообщений System V сопоставляется свой
Ядро хранит информацию о каждой очереди сообщений в виде структуры, определенной в заголовочном файле
struct msqid_ds {
struct ipc_perm msg_perm; /* Разрешения чтения и записи: раздел 3.3 */
struct msg *msg_first; /* указатель на первое сообщение в очереди */
struct msg *msg_last; /* указатель на последнее сообщение в очереди */
msglen_t msg_cbytes; /* размер очереди в байтах */
msgqnum_t msg_qnum; /* количество сообщений в очереди */
msglen_t msg_qbytes; /* максимальный размер очереди в байтах */
pid_t msg_lspid; /* идентификатор (pid) последнего процесса, вызвавшего msgsnd(); */
pid_t msg_lrpid; /* pid последнего msgrcv(); */
time_t msg_stime; /* время отправки последнего сообщения */
time_t msg_rtime; /* время последнего считывания сообщения */
time_t msg_ctime; /* время последнего вызова msgctl(), изменившего одно из полей структуры */
};
ПРИМЕЧАНИЕ
Unix 98 не требует наличия полей msg_first, msg_last и msg_cbytes. Тем не менее они имеются в большинстве существующих реализаций, производных от System V. Естественно, ничто не заставляет реализовывать очередь сообщений через связный список, который неявно предполагается при наличии полей msg_first и msg_last. Эти два указателя обычно указывают на участки памяти, принадлежащие ядру, и практически бесполезны для приложения.
Мы можем изобразить конкретную очередь сообщений, хранимую ядром как связный список, — рис. 6.1. В этой очереди три сообщения длиной 1, 2 и 3 байта с
