关于Fibers（纤程/用户态线程）核心原理与线程交互的问询

Hey there! Let's break down fibers clearly—they can feel opaque at first, especially when wrapping your head around how they interact with threads. Let's start with the core fundamentals you might have glossed over, then dive straight into the thread interaction piece that's tripping you up.

First, let's solidify the basics that separate fibers from threads and coroutines:

• Cooperative scheduling (the big one): Unlike OS threads (which are preemptively scheduled—your OS can yank control away from a thread at any time), fibers only give up control when you explicitly tell them to (via a yield call or blocking on a fiber-aware primitive). No unexpected context switches here.
• Ultra-lightweight context switches: Thread switches require the OS kernel to save/restore entire CPU registers, memory mappings, and kernel state—this is slow. Fiber switches happen entirely in user space: we just save the fiber's stack pointer and a few registers, then swap to another fiber's context. The overhead is negligible compared to threads.
• User-space scheduling: You (or a library like Boost.Fibers) control when fibers run. Threads are managed by the OS scheduler; fibers are managed by a user-level scheduler that lives within a thread.

This is where most people get stuck—let's break it down into concrete, actionable points:

• Fibers are tied to threads (but one thread can run many fibers): A fiber can't exist outside a thread. At any given moment, only one fiber is actively running on a thread. When a fiber yields, the user-space scheduler picks another fiber in that thread to run.
• Two common mapping models:
  • Single-threaded fiber pool: All fibers run on a single thread. This is perfect for I/O-bound workloads (like handling network requests or file reads) where you spend most of your time waiting. Instead of spawning dozens of threads (which have high overhead), you can run hundreds of fibers that yield when waiting, letting other fibers use the thread in the meantime.
  • Multi-threaded fiber scheduling: Use a pool of threads, each with its own fiber scheduler. This is for when you have CPU-bound fibers that need to utilize multiple cores. Libraries like Boost.Fibers can automatically distribute fibers across the thread pool, so busy fibers don't block each other.
• Synchronization: Use fiber-aware primitives:
  If you use regular thread mutexes or condition variables with fibers, you can run into deadlocks. For example: if Fiber A holds a mutex and yields, then Fiber B (on the same thread) tries to lock that mutex, it will block the entire thread—Fiber A can't run to release the mutex because the thread is stuck on Fiber B.
  Instead, use fiber-specific sync tools (like boost::fibers::mutex or boost::fibers::condition_variable). These primitives will yield the waiting fiber instead of blocking the thread, letting the scheduler run other fibers while waiting.

Quick Example: Fibers & Threads in C++ (Boost.Fibers) #

Here's a simple snippet to see how fibers map to threads:

#include <boost/fiber/all.hpp>
#include <iostream>
#include <thread>

void fiber_work(int id) {
    std::cout << "Fiber " << id << " running on thread: " << std::this_thread::get_id() << "\n";
    // Yield control to let another fiber run
    boost::this_fiber::yield();
    std::cout << "Fiber " << id << " resumed on thread: " << std::this_thread::get_id() << "\n";
}

int main() {
    // Case 1: Two fibers running on the main thread
    boost::fibers::fiber f1(fiber_work, 1);
    boost::fibers::fiber f2(fiber_work, 2);

    f1.join();
    f2.join();

    // Case 2: Fibers distributed across a thread pool (2 threads)
    boost::fibers::thread_pool pool(2);
    pool.post(fiber_work, 3);
    pool.post(fiber_work, 4);
    pool.join();

    return 0;
}

When you run this, you'll see fibers 1 and 2 share the main thread's ID, while fibers 3 and 4 run on the two pool threads (their IDs will differ from the main thread and each other).

Fibers are a tool to write concurrent code with lower overhead than threads, but they rely on cooperative control and user-space scheduling. The key to understanding their interaction with threads is remembering: fibers run on top of threads, and you can choose to map them to single or multiple threads depending on your workload. Always use fiber-aware synchronization to avoid blocking entire threads.

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