单线程/进程模式下使用pthread_mutex_*是否安全？冗余判断咨询

嘿，这个问题挺贴合实际开发场景的，我来分享下我的经验和理解：

1. 单线程/进程模式下使用pthread_mutex_*系列接口是否安全？ #

首先明确说：只要你遵循pthread规范正确使用，单线程下调用pthread_mutex_lock/unlock等接口是安全的，不会触发未定义行为。

不过有几个细节要注意：

• 必须确保mutex已经正确初始化：要么用PTHREAD_MUTEX_INITIALIZER做静态初始化，要么调用pthread_mutex_init()动态初始化（记得对应调用pthread_mutex_destroy()）。
• 单线程下如果对同一个未解锁的mutex重复调用pthread_mutex_lock()，会直接导致死锁——因为mutex默认是普通类型（PTHREAD_MUTEX_NORMAL），不允许递归加锁。不过你的代码里是成对调用lock和unlock，而且单线程模式下global.multiple为false，不会走到这些锁操作，所以正常情况下不会遇到这个问题。
• 从性能角度说，单线程下调用锁接口完全没必要，还会带来额外的系统调用或内存屏障开销，所以你的代码里加判断跳过锁操作是合理的。

2. 代码中两处if(global.multiple)判断是否冗余？ #

这得分场景来看：

情况一：global.multiple是程序启动时确定、运行中不会修改的常量 #

这种情况下，运行时的if判断其实有点冗余——你可以改用编译期宏定义来控制锁代码的编译，比如：

#ifdef MULTIPLE_MODE
#define LOCK() pthread_mutex_lock(&mutex)
#define UNLOCK() pthread_mutex_unlock(&mutex)
#else
#define LOCK() do {} while(0)
#define UNLOCK() do {} while(0)
#endif

// 代码里直接写：
LOCK();
updateSth();
UNLOCK();

这样编译时就会把单线程模式下的锁代码完全去掉，比运行时判断更高效，也更简洁。

情况二：global.multiple可能在运行时动态切换（非常见场景） #

如果你的程序支持在运行时从单线程切换到多线程模式（或者反过来），那这两个if判断就完全不冗余——必须每次都检查当前模式，决定是否需要加锁。不过这种动态切换模式的场景很少见，因为多线程/单线程模式通常是程序启动时就确定的，切换时往往需要重启程序来保证状态一致。

额外注意点 #

还要确认global.multiple变量的访问是否线程安全：如果在多线程模式下，这个变量有可能被修改，那读取它的时候需要加同步吗？一般来说，这个变量应该是程序启动时初始化后就不再修改的，所以没问题；如果确实需要动态修改，那要把它定义为原子变量（比如用pthread的原子操作），避免出现读取到半更新的值。

另外，重复写两次if(global.multiple)确实有点啰嗦，你可以把逻辑封装成宏或者inline函数，比如：

static inline void lock_if_needed(pthread_mutex_t *mutex) {
    if (global.multiple) {
        pthread_mutex_lock(mutex);
    }
}

static inline void unlock_if_needed(pthread_mutex_t *mutex) {
    if (global.multiple) {
        pthread_mutex_unlock(mutex);
    }
}

// 调用时：
lock_if_needed(&mutex);
updateSth();
unlock_if_needed(&mutex);

这样代码更整洁，也减少了重复代码的维护成本。

内容的提问来源于stack exchange，提问作者Sato