为什么 sem_timedwait() 没有醒来？

Question

我使用 eCos 开发嵌入式系统： 我在同一个进程中有 2 个线程和 1 个信号量。

1. 线程 A 将信号量初始化为 0，以便第一次尝试获取它时会阻塞。
2. 线程 A 向线程 B 发送命令，提供回调。
3. 线程 A 使用 sem_timedwait 等待信号量
4. 线程 B 处理命令并增加信号量
5. 线程 A 应该被唤醒但仍被阻塞

代码如下：

线程 A

static sem_t semaphore;

void callback()
{
    // Do some stuff
    int ret = sem_post(&semaphore);
    // print confirmation message
}

void foo()
{
    int ret = sem_init(&semaphore, 0, 0);
    if(ret != 0)
    {
        // print errno
    }

    struct timespec ts; 
    clock_gettime(CLOCK_REALTIME,&ts); // Get current date
    ts.tv_sec += 2; // Add 2s for the deadline

    send_command_to_thread_B(&callback);

    ret = sem_timedwait(&semaphore, &ts);
    if(ret != 0)
    {
        // print errno
    }

    // print waking up message
}

线程 B 中的内容不相关。

为了调试，我尝试了以下方法：

1. 使用sem_wait 而不是sem_timedwait 有效：线程 A 被阻塞，然后在回调后解锁。但我不想使用它，因为如果回调过程中出现故障，阻止信号量递增，线程 A 将永远等待。
2. 如果我不将 2s 添加到 timespec 结构中，sem_timedwait 会立即返回，errno 会设置为 ETIMEDOUT（似乎是合法的）。回调被调用，但对于线程 A 来说为时已晚。
3. 我在回调调用中放置了跟踪，以确保信号量确实从 0 增加到 1：所有过程都完成了，回调退出但线程 A 仍然被阻塞。

你们有什么线索吗？我错过了什么吗？

Answer 1

好吧，实际上这段代码一切正常，问题出在其他地方：我遇到了导致死锁的重入问题。
道德：小心保护您的资源和地址多线程上下文