On Jun 10, 2013, at 17:18 , Nathan Hjelm <hjelmn_at_[hidden]> 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:
> 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
> devel mailing list