Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: Add static initializer for opal_mutex_t
From: Nathan Hjelm (hjelmn_at_[hidden])
Date: 2013-06-10 11:18:37

On Sat, Jun 08, 2013 at 12:28:02PM +0200, George Bosilca wrote:
> All Windows objects that are managed as HANDLES can easily be modified to have static initializer. A clean solution is attached to the question at stackoverflow:

Not the cleanest solution (and I don't know how handles work) so I held off on proposing adding a static initializer until the windows code was gone.

> That being said I think having a static initializer for a synchronization object is a dangerous thing. It has many subtleties and too many hidden limitations. As an example they can only be used on the declaration of the object, and can't be safely used for locally static object (they must be global).

I have never seen any indication that a statically initialized mutex is not safe for static objecs. The man page for thread_mutex_init uses the static initializer on a static mutex:

> What are the instances in the Open MPI code where such a statically defined mutex need to be used before it has a chance of being correctly initialized?

MPI_T_thread_init may be called from any thread (or multiple threads at the same time). The current code uses atomics to protect the initialization of the mutex. I would prefer to declare the mpit lock like:

opal_mutex_t mpit_big_lock = OPAL_MUTEX_STATIC_INIT;

and remove the atomics. It would be much cleaner and should work fine on all currently supported platforms.