【工作问题记录】

1. 频繁获取共享内存地址，导致进程超时

现象： 进程在运行过程中，频繁获取共享内存地址，导致进程超时。 问题： 频繁获取共享内存地址，核心会引发性能损耗、资源泄漏、稳定性风险三类问题。

针对项目出现的超时问题，考虑到shm_open、mmap等是系统调用，每次调用都会从用户态切到内核态，频繁切换会消耗大量 CPU；且shm_open操作是基于内存的文件系统，频繁创建 / 打开会触发元数据读写、锁竞争，累积下来会显著拖慢程序，最终导致进程报超时错误。

解决： 用全局变量记录共享内存地址，避免频繁获取。

# file_A.c
void *shm_ptr = NULL;
void shm_ptr_gain()
{
    shm_ptr = 获取共享内存地址;
}

# file_B.c
extern void *shm_ptr;
void shm_ptr_use()
{
    # 在这里可以直接使用 shm_ptr
    printf("shm_ptr = %p\n", shm_ptr);
}

2. 接收不到通过UDP发送的雷达数据

现象： 通过UDP多播方式发送雷达数据，接收端有时能收到数据，有时收不到。 问题定位： （1）单步调试时recvfrom返回值不为-1，能正常接收到数据。考虑初始化的时间问题，接收端初始化时，可能还未完成绑定，导致收不到数据。于是，在初始化绑定后加入延时后，就能正常接收数据。但这种做法并没有解决根本问题，只是临时解决了超时问题。（2）检查接收端代码中，recvfrom后有对系统错误码errno的判断，如果errno不为EAGAIN或EWOULDBLOCK则开始解析雷达数据。假设初始化完成（非阻塞模式），且绑定成功，但此刻没有数据到达，recvfrom会立即返回-1，且errno会被设置为EAGAIN或EWOULDBLOCK；第二次循环时，有数据到达，recvfrom会返回数据长度，但errno没有被更新，仍为EAGAIN或EWOULDBLOCK，导致解析雷达数据的判断条件不满足，从而收不到数据。

解决： 根据recvfrom的返回值判断，若成功接收到数据则将errno重置为0，否则保持原值。