异步接口设计：异步回调、事件循环、Future/Promise模式在C语言中的实现

嵌入式系统里，异步编程是个绕不开的话题。

我早年做物联网网关时，遇到一个棘手问题：主控芯片要同时处理传感器采集、网络通信、UI刷新。如果用同步方式，一个阻塞就把整个系统卡死了。那时候我才真正意识到——异步接口设计，是嵌入式工程师的必修课。

为什么需要异步？

说白了，异步就是为了不让CPU闲着等I/O。

你想想看，MCU去读一个I2C传感器，可能要等几毫秒。这几毫秒如果干等着，系统响应就慢了。异步的思路是：发起请求，然后去干别的事，等数据准备好了再回来处理。

异步回调模式

这是最基础的异步实现方式。我在项目中用得最多。

// 定义回调函数类型
typedef void (*async_callback_t)(int status, void *user_data);

// 异步操作结构体
typedef struct {
    async_callback_t callback;
    void *user_data;
    uint32_t timeout_ms;
} async_operation_t;

// 发起异步请求
int async_request(async_operation_t *op) {
    // 将操作加入队列
    // 返回后立即执行
    return enqueue_operation(op);
}

// 使用示例
void sensor_read_done(int status, void *data) {
    if (status == 0) {
        float *value = (float *)data;
        printf("传感器值: %.2f\n", *value);
    }
}

async_operation_t op = {
    .callback = sensor_read_done,
    .user_data = &sensor_value,
    .timeout_ms = 100
};
async_request(&op);
// 这里可以继续做其他事

嗯，这里要注意：回调函数是在中断上下文还是任务上下文执行？我踩过这个坑——在中断里直接调用回调，结果回调里调用了printf，直接死机。后来我改成用消息队列把回调投递到任务上下文执行。

事件循环模式

事件循环是异步回调的升级版。它有一个中心调度器，不断从队列里取事件，然后分发给对应的处理器。

// 事件结构体
typedef struct {
    uint32_t event_id;
    void *data;
    size_t data_len;
} event_t;

// 事件处理器
typedef void (*event_handler_t)(event_t *evt);

// 事件循环
void event_loop_run(void) {
    event_t evt;
    while (1) {
        if (dequeue_event(&evt, portMAX_DELAY) == pdTRUE) {
            event_handler_t handler = find_handler(evt.event_id);
            if (handler) {
                handler(&evt);
            }
        }
    }
}

// 注册事件处理器
void register_handler(uint32_t event_id, event_handler_t handler) {
    // 将handler加入映射表
}

事件循环的好处是解耦。发送方只管发事件，接收方只管处理事件，双方不需要知道对方的存在。我在做智能家居网关时，把WiFi、蓝牙、Zigbee都抽象成事件源，主循环统一调度，代码结构清晰多了。

Future/Promise模式

这个模式在C++和JavaScript里很常见，但C语言也能实现。Future代表一个未来的结果，Promise是产生结果的承诺。

// Future结构体
typedef struct future_s {
    volatile bool ready;
    void *result;
    semaphore_t sem;
    struct future_s *next;
} future_t;

// Promise结构体
typedef struct {
    future_t *future;
    void (*resolve)(struct promise_s *p, void *result);
    void (*reject)(struct promise_s *p, int error);
} promise_t;

// 创建Promise
promise_t *promise_create(void) {
    promise_t *p = malloc(sizeof(promise_t));
    p->future = malloc(sizeof(future_t));
    p->future->ready = false;
    p->future->sem = xSemaphoreCreateBinary();
    p->future->next = NULL;
    p->resolve = promise_resolve;
    p->reject = promise_reject;
    return p;
}

// 等待Future结果
void *future_await(future_t *f) {
    xSemaphoreTake(f->sem, portMAX_DELAY);
    return f->result;
}

// 使用示例
void async_operation(promise_t *p) {
    // 模拟异步操作
    void *result = do_something();
    p->resolve(p, result);
}

promise_t *p = promise_create();
async_operation(p);
void *result = future_await(p->future);

Future/Promise模式最大的价值在于组合。你可以把多个异步操作串联起来，或者并行执行再合并结果。我在做OTA升级时，用Promise链实现了「下载固件→校验→写入→重启」的异步流水线，代码可读性比回调嵌套好太多了。

三种模式的融合使用

实际项目中，我很少只用一种模式。通常是混合使用：底层用回调，中间层用事件循环，上层用Future/Promise。

// 底层：回调
void uart_rx_callback(uint8_t byte) {
    event_t evt = {.event_id = EVT_UART_RX, .data = &byte, .data_len = 1};
    post_event(&evt);
}

// 中间层：事件循环
void event_handler(event_t *evt) {
    switch (evt->event_id) {
        case EVT_UART_RX:
            // 解析协议
            break;
    }
}

// 上层：Future/Promise
promise_t *send_command(uint8_t *cmd, size_t len) {
    promise_t *p = promise_create();
    // 发送命令，注册回调
    uart_send(cmd, len, p);
    return p;
}

这种分层设计，既保证了底层的高效，又提供了上层的便利。我做过一个项目，底层驱动用回调，中间用事件循环做协议解析，上层用Future/Promise给应用层提供接口。整个系统跑下来，CPU占用率不到15%。

异步接口设计原则

总结几条我这些年摸爬滚打总结出来的原则：

• 不要阻塞调用者：异步接口应该立即返回，耗时操作放到后台
• 明确生命周期：谁创建谁销毁，避免内存泄漏
• 错误处理要完整：超时、失败、取消都要有对应的回调
• 可重入设计：回调函数可能被多次调用，要做好状态管理
• 文档要详细：异步接口的调用时序、线程安全要求必须写清楚

我记得有一次，一个同事写的异步接口没有说明回调在哪个上下文执行，结果我在中断里调用了他的接口，回调又在中断里调用了我的接口，形成了递归死循环。从那以后，我要求所有异步接口必须明确标注「回调执行上下文」。

异步接口设计没有银弹。回调、事件循环、Future/Promise各有各的舞台。关键是根据你的系统规模、实时性要求、开发团队能力来选型。我见过用纯回调跑得很稳的小系统，也见过用Future/Promise写得一团糟的大项目。工具只是工具，用得好不好，全看人。