On Mon, Jun 10, 2013 at 06:53:36PM +0200, George Bosilca wrote: > > On Jun 10, 2013, at 17:18 , Nathan Hjelm <hje...@lanl.gov> wrote: > > > 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. > > Nothing really fancy, a HANDLE is basically an untyped location storage (a > void*). > > >> 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 > > It is thread safe for global static objects, but might not be thread safe for > local static objects. > > >> 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. > > OK, almost a corner-case. > > > how does mutex static initializer works > > A more detailed explanation in the "Static Initializers for Mutexes and > Condition Variables" part of the > http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_init.html
Interesting. We could add a caveat to the definition describing where static initialization might not be optimal. Either that or we could implement a opal_once to do the initialization in this case. I would have to look into the solaris thread case to see if a once function is possible there. -Nathan
