Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: Add static initializer for opal_mutex_t
From: Ralph Castain (rhc_at_[hidden])
Date: 2013-06-11 12:25:14


On Jun 11, 2013, at 9:16 AM, Nathan Hjelm <hjelmn_at_[hidden]> wrote:

> On Tue, Jun 11, 2013 at 09:13:01AM -0700, Ralph Castain wrote:
>>
>> On Jun 11, 2013, at 9:09 AM, Nathan Hjelm <hjelmn_at_[hidden]> wrote:
>>
>>> On Mon, Jun 10, 2013 at 06:53:36PM +0200, George Bosilca wrote:
>>>>
>>>> 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:
>>>>>> 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
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel