CODEWITHSUNDEEP
pthreadssignalsmutexcancellationresource-cleanup
user4385532
user4385532

Reputation:

Am I supposed to unlock mutexes in a cleanup handler?

A couple of quotes from the manual.

Quoting man 3 pthread_mutex_unlock:

None of the mutex functions is a cancellation point, not even pthread_mutex_lock, in spite of the fact that it can suspend a thread for arbitrary durations. This way, the status of mutexes at cancellation points is predictable, allowing cancellation handlers to unlock precisely those mutexes that need to be unlocked before the thread stops executing.

But one paragraph later it is written that:

The mutex functions are not async-signal safe. What this means is that they should not be called from a signal handler. In particular, calling pthread_mutex_lock or pthread_mutex_unlock from a signal handler may deadlock the calling thread.

OK, so the manual orders me to unlock mutexes in a cleanup handler, but prohibits me from unlockin mutexes in a signal handler. Well, quoting man 3 pthread_cancel:

On Linux, cancellation is implemented using signals.

Ah. So a thread is cancelled by receiving a signal.

Doesn’t this make a cancellation cleanup handler actually a signal handler? Or maybe rather, I dunno, the cleanup handler is being called from a signal handler whose default action is to call functions installed by pthread_cleanup_push? One cannot deny that these cleanup handlers are called when a signal is being received.

But this would make the manual contradict it’s own statements…

How to understand things properly?

Upvotes: 2

Views: 742

Answers (1)

caf
caf

Reputation: 239071

The fact that cancellation is handled using signals on Linux is an implementation detail. It doesn't mean you're only allowed to use async-signal-safe functions in them.

At least for deferred cancellation at a cancellation point, POSIX doesn't limit the functions that can be called, so the implementation has to make that work.

Upvotes: 1

Related Questions