Description
In reviewing bug https://svn.open-mpi.org/trac/ompi/ticket/176, I have determined that the locking code in source:/trunk/ompi/attribute/attribute.c may not be thread safe in all cases and needs to be audited. It was written with the best of intentions :-) but then never tested and I think there are some obscure race conditions that ''could'' happen.
For example, in ompi_attr_create_keyval(), we have the following:
OPAL_THREAD_LOCK(&alock);
ret = CREATE_KEY(key);
if (OMPI_SUCCESS == ret) {
ret = opal_hash_table_set_value_uint32(keyval_hash, *key, attr);
}
OPAL_THREAD_UNLOCK(&alock);
if (OMPI_SUCCESS != ret) {
return ret;
}
/* Fill in the list item */
attr->copy_attr_fn = copy_attr_fn;
/* ...fill in more attr->values ... */
This could clearly be a problem since we set the empty keyval on the hash and therefore it's available to any other thread as soon as the lock is released -- potentially ''before'' we finish setting all the values on the attr variable (which is poorly named -- it's a keyval, not an attribute).
This one problem is easily fixed (ensure to setup attr before we assign it to the keyval hash), but it reflects that the rest of the attribute code should really be audited. Hence, this ticket is a placemarker to remember to audit this code because it may not be thread safe.