This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
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:
>>> 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.
> devel mailing list