UNIX: взаимодействие процессов

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. 

ГЛАВА 6 Очереди сообщений System V

6.1. Введениеы

Каждой очереди сообщений System V сопоставляется свой идентификатор очереди сообщений. Любой процесс с соответствующими привилегиями (раздел 3.5) может поместить сообщение в очередь, и любой процесс с другими соответствующими привилегиями может сообщение из очереди считать. Как и для очередей сообщений Posix, для помещения сообщения в очередь 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 байта с типами 100, 200 и 300 соответственно.