UNPV2 学习：Posix Message Queues Exercise 解答记录

Exercise

5.1 只指定 mq_maxmsg 中的一个，未指定则使用默认值

  struct mq_attr default_attr;
  ...........................
  if (optind != argc - 1)
		err_quit("usage: mqcreate [ -e ] [ -m maxmsg -z msgsize ] <name>");
	
	mqd = Mq_open(argv[optind], flags, FILE_MODE, NULL);
	
	Mq_getattr(mqd, &default_attr);
	
	attr.mq_maxmsg = attr.mq_maxmsg ? attr.mq_maxmsg:default_attr.mq_maxmsg;
	attr.mq_msgsize = attr.mq_msgsize ? attr.mq_msgsize:default_attr.mq_msgsize;

	Mq_setattr(mqd, &attr, NULL);

未从 sysconf 中找到获取该项目的类型。

5.2 去掉 Figure5.5 中信号处理函数执行 mq_notify 的逻辑

只能收到第一条消息，第二条消息无法处理。mq_notify 注册的消息通知事件在被通知一次后会自动移除，在信号处理函数中不重新注册则无法捕获后续的事件。同时第二条消息还在队列中也不会触发通知事件，进程将一直空转。

5.3 去掉 Figure5.5 中信号处理函数执行 mq_receive 的逻辑

[longyu@debian:09:08:46] pxmsg $ ./mqnotifysig1 /test
SIGUSR1 received

只能收到一个 SIGUSR1 信号，由于不从队列中接收，只在投递第一条消息的时候会触发通知，后续消息由于队列不为空，尽管在信号处理程序中注册了 mq_notify，内核不会发送通知。

5.4 去掉 SIGRTMIN 宏前的 int 型强转操作的影响

debian11 中 SIGRTMIN 与 SIGRTMAX 宏定义如下：

365 /* Return number of available real-time signal with highest priority.  */
366 extern int __libc_current_sigrtmin (void) __THROW;
367 /* Return number of available real-time signal with lowest priority.  */
368 extern int __libc_current_sigrtmax (void) __THROW;
369 
370 #define SIGRTMIN        (__libc_current_sigrtmin ())
371 #define SIGRTMAX        (__libc_current_sigrtmax ())

在我的 debian11 中测试去掉强转操作没有任何影响，编译不告警生成的程序也能够正常运行。

5.5 观察当前平台是否用内存映射 I/O 方式实现消息队列

debian11 中设定 mq_maxmsg 为 10 万时无法成功创建消息队列， 使用 root 用户设置 ulimit -q 也不能成功，strace 跟踪发现 mq_open 系统调用返回 -EINVAL，阅读代码找到如下相关内容：

		ret = -EINVAL;
		if (info->attr.mq_maxmsg <= 0 || info->attr.mq_msgsize <= 0)
			goto out_inode;
		if (capable(CAP_SYS_RESOURCE)) {
			if (info->attr.mq_maxmsg > HARD_MSGMAX ||
			    info->attr.mq_msgsize > HARD_MSGSIZEMAX)
				goto out_inode;
		} else {
			if (info->attr.mq_maxmsg > ipc_ns->mq_msg_max ||
					info->attr.mq_msgsize > ipc_ns->mq_msgsize_max)
				goto out_inode;
		}

当设置了 SYS_RESOURCE capability 时，配置的 mq_maxmsg 不能超过 HARD_MSGMAX（65536），mq_msgsize 不能超过 HARD_MSGSIZEMAX（16M）。

相关宏定义如下：

#define DFLT_QUEUESMAX		      256
#define MIN_MSGMAX			1
#define DFLT_MSG		       10U
#define DFLT_MSGMAX		       10
#define HARD_MSGMAX		    65536
#define MIN_MSGSIZEMAX		      128
#define DFLT_MSGSIZE		     8192U
#define DFLT_MSGSIZEMAX		     8192
#define HARD_MSGSIZEMAX	    (16*1024*1024)

ipc_ns 中的默认配置在 mq_init_ns 中初始化，此函数源码如下：

int mq_init_ns(struct ipc_namespace *ns)
{
	struct vfsmount *m;

	ns->mq_queues_count  = 0;
	ns->mq_queues_max    = DFLT_QUEUESMAX;
	ns->mq_msg_max       = DFLT_MSGMAX;
	ns->mq_msgsize_max   = DFLT_MSGSIZEMAX;
	ns->mq_msg_default   = DFLT_MSG;
	ns->mq_msgsize_default  = DFLT_MSGSIZE;

	m = mq_create_mount(ns);
	if (IS_ERR(m))
		return PTR_ERR(m);
	ns->mq_mnt = m;
	return 0;
}

默认最大的 mq_maxmsg 为 10，最大的 mq_msgsize 为 8192。

5.6 内存映射 I/O 实现中，mq_send memcpy 拷贝长度为 0 大小的消息

分析代码，接收者仍旧能够接收到这条消息，接收者的 memcpy 拷贝动作也不会执行，此实现在消息 len 为 0 时仍旧能够正常工作，linux 内核也有相同的行为，发送一个 len 为 0 的消息可以正常处理。

5.7 支持全双工通信需要创建几个消息队列？

需要创建两个消息队列

5.8 Figure 5.24 中为什么不销毁 mutex 与条件变量

munmap 函数并不会立刻释放内存，内部也有一个引用计数，只有当最后一个 munmap 被调用时内存才会真正释放。如果在 mq_close 中直接销毁位于共享内存中的互斥锁与条件变量，同时有人尝试访问时就会产生异常，因此代码中并没有主动销毁互斥锁与条件变量，它的销毁实际是在内核回收 mmap 映射的共享内存时进行的，此时不需要任何用户态干预动作。