On Tue, Jun 11, 2013 at 09:13:01AM -0700, Ralph Castain wrote: > > On Jun 11, 2013, at 9:09 AM, Nathan Hjelm <hje...@lanl.gov> wrote: > > > 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. > > We don't support solaris threads any more - haven't for quite some time.
If that is the case would there be any objection to the removal of the solaris thread code from opal_mutex? -Nathan
