Отмена потока с заблокированным мьютексом не разблокирует мьютекс

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

используя RAII чтобы разблокировать мьютекс будет быть более надежным. На GNU / Linux pthread_cancel реализовано со специальным исключением типа __cxxabi::__forced_unwind, поэтому, когда поток отменяется исключение и стек. Если мьютекс заблокирован типом RAII, то его деструктор будет гарантированно запущен, если стек размотан __forced_unwind исключения. Boost Thread предоставляет портативную библиотеку C++, которая обертывает Pthreads и гораздо проще в использовании. Он обеспечивает тип RAII boost::mutex и другие полезные абстракции. Boost Thread также предоставляет свой собственный механизм "прерывания потока", который похож на отмену Pthread, но не то же самое, и точки отмены Pthread (например,connect) не стимулировать точки прерывания потока, что может быть полезно для некоторых приложений. Однако в случае вашего клиента, так как точка отмены должна прервать connect вызов они, вероятно, хотят придерживаться Pthread отмена. (Непереносимый) способ GNU / Linux реализует отмену в качестве исключения означает, что он будет хорошо работать с boost::mutex.

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

другой вариант-использовать надежный мьютекс, который создается зову pthread_mutexattr_setrobust на pthread_mutexattr_t прежде, чем инициализация мьютекса. Если поток умирает, удерживая надежный мьютекс, ядро запишет его, чтобы следующий поток, который пытается заблокировать мьютекс, получил специальный код ошибки EOWNERDEAD. Если это возможно, новый поток может сделать данные, защищенные потоком, согласованными снова и взять на себя ответственность за мьютекс. Это намного сложнее использовать правильно, чем просто использовать тип RAII для блокировки и разблокировки мьютекса.

A совершенно другим подходом было бы решить, действительно ли вам нужно удерживать блокировку мьютекса при вызове connect. Проведение мьютексов во время медленных операций-не очень хорошая идея. Не могли бы вы позвонить connect затем, если успешная блокировка мьютекса и обновление любых общих данных защищаются мьютексом?

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