pthread_mutex_lock调用位置疑问及进程同步相关书籍推荐

Great questions about mutex placement and behavior—let’s break this down clearly, including a critical note on your sample code.

1. When to call pthread_mutex_lock before pthread_create? #

There are very specific, niche scenarios where you’d lock a mutex before creating threads, all centered around strictly controlling thread execution order or protecting uninitialized shared state:

• Enforcing startup sequencing: If you need one thread to finish critical setup work (like initializing shared resources) before any other threads can run, you can lock the mutex in the main thread, spawn the workers, then unlock only after setup is complete. Worker threads will block on pthread_mutex_lock until the main thread releases the lock.
• Preventing premature resource access: If your shared data isn’t fully initialized when threads start, locking upfront ensures threads can’t touch the state until you’ve finished configuring it.

Important caveat: This pattern is rare. Most of the time, you want threads to manage mutex locking/unlocking internally—it keeps synchronization logic tied directly to the code that uses the shared resource, making the program easier to maintain and debug.

2. Core Differences Between Pre-Creation Locking and Thread-Internal Locking #

First, let’s flag a critical issue in your current code: Thread fct1 calls pthread_mutex_unlock without ever holding the lock (the main thread locked it). This is undefined behavior in POSIX threads—only the thread that acquires a mutex can unlock it. Your code appears to work purely by coincidence:

• The main thread holds the mutex, so fct2 blocks on pthread_mutex_lock until fct1 (illegally) unlocks it.
• fct1 modifies the shared array T without holding the mutex, which is thread-unsafe—you’re just lucky fct2 can’t interfere.

Now, the key distinctions between the two approaches:

Approach 1: Lock before pthread_create (your current code) #

• External synchronization control: The main thread dictates when threads can access critical sections, not the threads themselves.
• High risk of undefined behavior: Unlocking a mutex you don’t own can lead to crashes, deadlocks, or unpredictable behavior in more complex programs.
• Extremely coarse granularity: All writes from fct1 happen before all reads from fct2—this isn’t using the mutex for its intended purpose (protecting shared resource access), but rather as a crude execution order tool.

Approach 2: Lock inside thread functions (the correct pattern) #

• Encapsulated safety: Each thread takes responsibility for locking/unlocking when accessing shared resources, which is the standard, reliable practice for pthread synchronization.
• Proper mutex usage: Only threads holding the mutex modify/read shared data, eliminating race conditions entirely.
• Flexible granularity: You can adjust lock scope (e.g., lock per array element instead of the entire loop) if needed, while maintaining thread safety.

Your test showed the same result because your specific code’s strict "all writes first, all reads second" flow aligned with the accidental behavior of the incorrect approach. But this isn’t a reliable outcome—add a sleep in fct1 or modify shared data elsewhere, and you’ll see race conditions or crashes.

Recommended Book #

For deep, authoritative coverage of pthread synchronization (including mutexes, semaphores, and real-world best practices), grab Programming with POSIX Threads by David R. Butenhof. It’s the definitive guide to POSIX threads, packed with practical examples and explanations of edge cases you’ll encounter. If you want a broader UNIX programming reference that includes threads, Advanced Programming in the UNIX Environment (W. Richard Stevens) is also an excellent choice.

内容的提问来源于stack exchange，提问作者sahli mohamed mehdi M sahli