TL;DR

У меня есть домашнее задание, где мне нужно реализовать синхронизацию потоков. Во время реализации я был обеспокоен тем, что pthread_cond_wait() также блокирует мьютекс, если он ложно просыпается, а не только если он успешно просыпается.

Задача

Задача представляет собой проблему работника/доставки, где есть рабочие потоки и потоки управления, которые предоставляют заказы для рабочих. Для этой цели существует список заказов, из которого рабочие получают заказы, а поток управления размещает заказы. Список заказов является общим объектом и требует синхронизации.

Мое решение до сих пор

Я подумал, что для этой проблемы мне нужен монитор для списка, чтобы защитить его от обращений на пустом месте или от депозитов, когда он заполнен.

void deposit_order(order_list* ol, order* o){
    pthread_mutex_lock(&(ol->mut_order_access));
    while(get_count(ol) >= MAX_ORDERS) {
        pthread_cond_wait(&(ol->cond_not_full), &(ol->mut_order_access));
    }

    ol->orders[ol->head] = o;
    ol->head = (ol->head+1)%MAX_ORDERS;
    ol->count++;
    
    pthread_cond_signal(&(ol->cond_not_empty));
    pthread_mutex_unlock(&(ol->mut_order_access));
}

order* get_order(order_list* ol) {
    pthread_mutex_lock(&(ol->mut_order_access));
    while(get_count(ol) <= 0) {
        pthread_cond_wait(&(ol->cond_not_empty), &(ol->mut_order_access));
    }
    order* o;
    
    o = ol->orders[ol->tail];
    ol->tail = (ol->tail+1)%MAX_ORDERS;
    ol->count--;
    
    pthread_cond_signal(&(ol->cond_not_full));
    pthread_mutex_unlock(&(ol->mut_order_access));
    return o;
}

Я считаю, что не так важно, что содержат структуры, поскольку тема заключается в том, как синхронизировать доступ. Очевидно, что структура order_list содержит mutex и две условные переменные для передачи сигнала другому потоку. Таким образом, если работник удаляет задачу из списка, он сигнализирует потоку управления «не пусто», чтобы он мог внести дополнительный заказ. Если руководство размещает заказ, это сигнализирует рабочим потокам «не пустой», поэтому один поток может удалить заказ из списка.

Мои опасения

Пока все хорошо, но теперь я думаю, что есть одно событие, когда вышеуказанное решение может быть критическим, и это «ложное пробуждение». Из эта тема я узнал, что поток не может ложно проснуться, если соответствующий мьютекс, а именно mut_order_access, заблокирован другим потоком. Но что, если в списке есть, например, только один заказ, так что get_count(ol) >= MAX_ORDERS не выполняется и поток ложно просыпается от ожидания, проверяет условие и помечает его как не верное и выпрыгивает из цикла. Затем другой поток получает сигнал и просыпается, как обычно, блокируя мьютекс после того, как предыдущий поток уже находится в критической области. Итак, теперь оба потока окажутся в критической области, что приведет к сбою.

Вопрос

Таким образом, описанное выше может произойти только в том случае, если поток не блокирует мьютекс, когда он ложно просыпается, поэтому блокирует ли он мьютекс при ложном пробуждении или нет?