Обработка исключений C++ в критической секции (pthreads)

В C++ мы используем Инициализация получения ресурсов (RAII) для защиты от исключений.

Это действительно бомбит после исключения? Судя по вашему фрагменту, гораздо более вероятно, что у вас просто плохая синхронизация. Это начинается с имени вашего мьютекса: «writeMutex». Это не сработает, если есть также «readMutex». Все операции чтения, просмотра и записи должны быть заблокированы одним и тем же мьютексом.

Вызывает ли блок try/catch немедленный выход, если он перехватывает исключение std::bad_alloc?

Нет. Если std::bad_alloc выброшен внутри блока try {...}, сработает код в блоке catch {...}.

Если ваша программа на самом деле дает сбой, то кажется, что либо ваш вызов push_back генерирует какое-то исключение, отличное от bad_alloc (которое не обрабатывается в вашем коде), либо bad_alloc генерируется где-то за пределами блока try {...}.

Кстати, вы действительно хотите использовать здесь блок try...catch?

плюс

как выглядит поп

создайте класс-оболочку блокировки, который автоматически освободит блокировку, когда она выйдет за пределы области действия (как в комментарии RAII)

c++ не имеет finally (спасибо мистеру Стустропу, который был строптивым)

я бы поймал std::exception или вообще ничего (утки опустили голову для войны с пламенем). Если вы ничего не поймаете, вам нужна обертка

Что касается релиза/отладки: Да, вы часто будете сталкиваться с изменением условий гонки между двумя типами сборок. Когда вы имеете дело с синхронизацией, ваши потоки будут работать с разным уровнем обучения. Хорошо написанные потоки в основном будут выполняться одновременно, в то время как плохо написанные потоки будут высоко синхронизированы друг с другом. Все типы синхронизации приводят к некоторому синхронному поведению. Как будто синхронность и синхронизация произошли от одного и того же корня слова...

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

Вам нужно использовать RAII
Это в основном означает использование конструктора/деструктора для блокировки/разблокировки ресурса.
Это гарантирует, что мьютекс всегда будет разблокирован, даже если существуют исключения.

Вы должны использовать только один мьютекс для доступа к списку.
Даже если у вас есть мьютекс только для чтения, который используется потоком, который только читает. Это не означает, что безопасно читать, когда другой поток обновляет очередь. Очередь может находиться в некотором промежуточном состоянии, вызванном вызовом потока push(), в то время как другой поток пытается перейти во включенное промежуточное состояние.

class Locker
{
    public:
        Locker(pthread_mutex_t &lock)
            :m_mutex(lock)
        {
            pthread_mutex_lock(&m_mutex);
        }
        ~Locker()
        {
            pthread_mutex_unlock(&m_mutex);
        }
    private:
        pthread_mutex_t&    m_mutex;
};

int Queue::push( WorkUnit unit )
{
    // building the object lock calls the constructor thus locking the mutex.
    Locker  lock(_writeMutex);
    int errorCode = 0;

    try
    {
        _queue.push_back( unit );
    }
    catch( std::bad_alloc )  // Other exceptions may happen here.
    {                        // You catch one that you handle locally via error codes. 
        errorCode = 1;       // That is fine. But there are other exceptions to think about.
    }

    return errorCode;
}  // lock destructor called here. Thus unlocking the mutex.

PS. Я ненавижу использование символа подчеркивания в начале.
Хотя технически здесь все в порядке (предполагая переменные-члены), в нем так легко запутаться, что я предпочитаю не добавлять '' перед идентификаторами. См. Что такое правила о использование символа подчеркивания в идентификаторе C++? для полного списка правил, которые нужно делать с '' в именах идентификаторов.

Предыдущий пример кода с классом Locker имеет серьезную проблему: что вы делаете, когда и если pthread_mutex_lock() терпит неудачу? Ответ заключается в том, что в этот момент вы должны сгенерировать исключение из конструктора, и оно может быть перехвачено. Отлично. Тем не менее, согласно спецификациям исключений С++, создание исключения из деструктора недопустимо. КАК ВЫ СПРАВЛЯЕТЕСЬ С ОШИБКАМИ pthread_mutex_unlock?

Запуск кода под любым инструментальным программным обеспечением бесполезен. Вы должны исправить код, который работает, а не запускать его под valgrind.

В C это работает отлично:

pthread_cleanup_pop( 0 );
r = pthread_mutex_unlock( &mutex );
if ( r != 0 )
{
    /* Explicit error handling at point of occurance goes here. */
}

Но поскольку C++ — это программный аборт, просто нет разумного способа с какой-либо степенью уверенности справляться с ошибками многопоточного кодирования. Безмозглые идеи вроде включения pthread_mutex_t в класс, добавляющий какую-то переменную состояния, просто мертвы для мозга. Следующий код просто не работает:

Locker::~Locker()
{
    if ( pthread_mutex_unlock( &mutex ) != 0 )
    {
        failed = true; // Nonsense.
    }
}

И причина этого в том, что после возврата pthread_mutex_unlock() этот поток вполне может быть вырезан из процессора - вытеснен. Это означает, что общедоступная переменная .failed по-прежнему будет ложной. Другие потоки, просматривающие его, получат неверную информацию - переменная состояния говорит об отсутствии сбоев, в то время как pthread_mutex_unlock() не удалось. Даже если по какой-то причине эти два оператора выполняются одновременно, этот поток может быть вытеснен до возврата ~Locker(), а другие потоки могут изменить значение .failed. Суть в том, что эти схемы не работают — нет атомарного механизма проверки и установки для переменных, определяемых приложением.

Некоторые говорят, что деструкторы никогда не должны иметь код, который дает сбой. Все остальное — плохой дизайн. Хорошо. Мне просто любопытно посмотреть, что является хорошим дизайном, чтобы быть 100% исключением и потокобезопасным в С++.