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: > http://stackoverflow.com/questions/3555859/is-it-possible-to-do-static-initialization-of-mutexes-in-windows
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: http://linux.die.net/man/3/pthread_mutex_init > 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. -Nathan
