Great question! The performance differences between these three threading libraries boil down to their abstraction layers, underlying implementations, platform optimizations, and feature sets. Let’s break this down step by step:

1. Abstraction Level & Overhead #

• POSIX Threads (pthreads): This is the lowest-level library here—it directly interfaces with the Linux/Unix kernel’s threading primitives. There’s almost no extra abstraction overhead; when you call pthread_create() or pthread_mutex_lock(), you’re essentially invoking kernel syscalls directly. This makes it the most lightweight for raw, platform-specific operations.
• STD Thread: Introduced in C11, the standard library’s threading API is a cross-platform abstraction. Under the hood, it typically wraps pthreads on Linux/Unix and Windows Threads on Windows. To maintain compliance with the C memory model and cross-platform consistency, it adds a thin layer of abstraction—this might include extra memory barriers, consistency checks, or standardized error handling that adds tiny overhead compared to raw pthreads.
• Boost Thread: Before C11, Boost Thread was the de facto standard for portable C threading. Today, it still builds on native OS primitives but offers more features than STD Thread (like thread interruption, advanced thread groups, or flexible thread-local storage). These extra features can introduce minor runtime overhead if you use them, though basic thread operations (create, join, mutex locks) are often comparable to STD Thread or even optimized closer to pthreads in some cases.

2. Scheduling & OS Interaction #

• pthreads: Gives you direct access to OS-level scheduling controls—you can set thread priority (pthread_setschedparam()), CPU affinity (pthread_setaffinity_np()), and fine-tune scheduling policies. This level of control lets you optimize for specific workloads (e.g., pinning real-time threads to dedicated cores) that can drastically improve performance in latency-sensitive applications.
• STD Thread: The C++ standard intentionally limits low-level scheduling controls to maintain portability. You can’t directly set thread priority or affinity using standard API calls—you’d need to use platform-specific extensions (like casting std::thread::native_handle() to a pthread_t on Linux) to access these features. Without these workarounds, STD Thread might not leverage OS-specific optimizations that pthreads can.
• Boost Thread: While also cross-platform, Boost provides more scheduling flexibility than STD Thread. For example, boost::thread lets you set priority or affinity through its API (with platform-specific implementations under the hood), bridging the gap between portability and low-level control. This can lead to better performance than STD Thread in scenarios where scheduling tweaks matter.

3. Synchronization Primitive Implementations #

The performance of mutexes, condition variables, and other sync primitives is a big contributor to overall threading performance:

• pthreads: Native sync primitives (pthread_mutex_t, pthread_cond_t) are heavily optimized by OS vendors for their specific kernels. They’re tuned for common workloads (e.g., fast path for uncontended locks) and integrate tightly with the kernel’s scheduler.
• STD Thread: std::mutex, std::condition_variable, etc., must adhere to the C++ memory model, which requires strict consistency guarantees. This can lead to slightly more overhead in some cases—for example, std::mutex might include extra checks for recursive locking (unless you use std::recursive_mutex) or enforce memory barriers that are stricter than what pthreads uses by default.
• Boost Thread: Boost’s sync primitives have evolved alongside the C++ standard. Early versions had their own implementations, but modern Boost uses native primitives where possible, aligning with STD Thread’s behavior. However, Boost offers additional primitives (like boost::spinlock or lock-free data structures) that aren’t in the standard, which can be more performant for specific use cases (e.g., short-lived locks where spinning is better than context switching).

4. Platform Optimization Focus #

• pthreads: As a Linux/Unix native library, it’s continuously optimized by kernel developers for the target OS. Every kernel update might include tweaks to pthread performance, making it the most optimized option for that platform.
• STD Thread: Since it’s designed to work across all C++-supported platforms, the implementation can’t prioritize one OS’s optimizations over another. For example, the same std::thread code has to work well on Linux, Windows, and macOS, which means some platform-specific optimizations might be left on the table.
• Boost Thread: While cross-platform, Boost’s maintainers often add platform-specific optimizations that the standard library can’t (due to strict standard compliance). For example, on Linux, Boost might use newer pthread features before they’re exposed through the standard API, giving it a performance edge in certain scenarios.

Wrap-Up #

In most basic threading scenarios (creating threads, simple mutex locks), the performance differences between these libraries are negligible. But as your workload becomes more complex—with heavy synchronization, real-time requirements, or platform-specific needs—the gaps start to show:

• Use pthreads if you need maximum control and raw performance on Linux/Unix.
• Use STD Thread for cross-platform code that prioritizes standard compliance and minimal dependencies.
• Use Boost Thread if you want cross-platform portability plus advanced features and better low-level control than the standard library offers.

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