Deprecatated pthread functions

[Artyom Abakumov]

Hello.

I recently built a handmade trace plugin and encountered an error when trying to use it on another machine. The error was:

undefined symbol: pthread_mutexattr_setrobust_np

Upon investigation, I noticed that the issue arises when autogen detects the presence of pthread_mutexattr_setrobust_np. Specifically, the HAVE_PTHREAD_MUTEXATTR_SETROBUST_NP define appears, which seems to trigger the error. However, when this detection does not occur, the error disappears.

Digging deeper into the code, I found that there are some old checks (approximately 13 years old) related to USE_ROBUST_MUTEX and BUGGY_LINUX_MUTEX defines. These defines trigger functions calls like pthread_yield, pthread_mutex_consistent_np, and pthread_mutexattr_setrobust_np, which are deprecated and (As I can see) have been removed in modern systems.

Are these USE_ROBUST_MUTEX checks still relevant in the current codebase? Given that the functions are deprecated, I believe it would be best to remove them to avoid compatibility issues on modern systems.

[Alex Peshkoff]

On 7/22/25 15:39, Artyom Abakumov wrote:
> Hello.
> I recently built a handmade trace plugin and encountered an error when
> trying to use it on another machine. The error was:
>

> /undefined symbol: pthread_mutexattr_setrobust_np/

>
> Upon investigation, I noticed that the issue arises when autogen
> detects the presence of pthread_mutexattr_setrobust_np. Specifically,

> the _HAVE_PTHREAD_MUTEXATTR_SETROBUST_NP_ define appears, which seems

> to trigger the error. However, when this detection does not occur, the
> error disappears.
>
> Digging deeper into the code, I found that there are some old checks
> (approximately 13 years old)

Or even earlier...

> related to _USE_ROBUST_MUTEX_ and _BUGGY_LINUX_MUTEX_ defines. These
> defines trigger functions calls like *pthread_yield*,
> *pthread_mutex_consistent_np*, and *pthread_mutexattr_setrobust_np*,

> which are deprecated and (As I can see) have been removed in modern
> systems.
>

> Are these _USE_ROBUST_MUTEX_ checks still relevant in the current

> codebase? Given that the functions are deprecated, I believe it would
> be best to remove them to avoid compatibility issues on modern systems.

_USE_ROBUST_MUTEX_ is relevant in the current codebase - if system
supports robustness it must be used, that protects from global hang in a
case when classic process dies inside lock manager. Not sure for check -
may be robust mutexes are supported now everywhere.

The problem with use of robust mutexes on linux was that
/pthread_mutexattr_setrobust /call does not return error when mutex
robustness is not supported (should according to posix standard, but
glibc developers sometimes treat standard in very wide way), only
pthread_mutex_init() returns an error when sees unsupported attr. That's
why all that "dance" around shared mutex creation.

What about "_np" in the end of function - 15 years ago only this call
was present in glibc (it was new feature), standard
*pthread_mutexattr_setrobust *was missing. I think now it's time to
switch to *pthread_mutexattr_setrobust* use but keep all remaining logic
around as is - I very much doubt glibc got better regarding exact
following posix standard. Though careful check is useful probably.

[Artyom Abakumov]

Thanks for the explanation. Interesting history and technical details.

вторник, 22 июля 2025 г. в 17:39:55 UTC+3, Alex Peshkoff: