Avoid static initialization of recursive mutexes #12034
Conversation
There is no portable way to statically initialize recursive mutexes. Where possible avoid doing so, and where not possible add a specialized __constructor__ (thanks @eschnett for the patch). Fixes open-mpi#12029. Signed-off-by: George Bosilca <[email protected]>
ompi/instance/instance.c
Outdated
| static opal_recursive_mutex_t instance_lock = OPAL_RECURSIVE_MUTEX_STATIC_INIT; | ||
| #else | ||
| static opal_recursive_mutex_t instance_lock; | ||
| __attribute__((__constructor__)) static void instance_lock_init(void) { |
There was a problem hiding this comment.
The constructor attribute isn't part of the C standard so we should check if it is actually available. What do we do if it isn't?
There was a problem hiding this comment.
All platforms supporting PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP or PTHREAD_RECURSIVE_MUTEX_INITIALIZER remain covered as before. The ones where they are not defined but where we have constructor will be now covered. For the rest of them, one could argue that we could provide support for .init but that would be more than what I'm willing to invest in this.
There is a single instance of a statically initialized recursive mutex. It is not clear to me why the instance code needs a recursive mutex, but I'm not going to dig deeper.
The only remaining statically initialized recursive mutex has now support for the constructor attribute. Signed-off-by: George Bosilca <[email protected]>
|
@bosilca Ok to merge and cherry pick to v5.0.x? |
bosilca
deleted the
topic/fixes_static_initialization_of_recursive_mutexes
branch
There is no portable way to statically initialize recursive mutexes. Where possible avoid doing so, and where not possible add a specialized constructor (thanks @eschnett for the patch).
Fixes #12029.