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. > > -Nathan > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
