On Jun 11, 2013, at 9:16 AM, Nathan Hjelm <hje...@lanl.gov> wrote: > 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?
Don't see why - even when Sun was still active, they agreed to standardize on pthreads as their compilers progressed to that point > > -Nathan > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
