George, Your idea makes sense. Is anyone working on it? If not, I'll try.
Regards, KAWASHIMA Takahiro > Takahiro, > > Thanks for the patch. I deplore the lost of the hash table in the attribute > management, as the potential of transforming all attributes operation to a > linear complexity is not very appealing. > > As you already took the decision C, it means that at the communicator > destruction stage the hash table is not relevant anymore. Thus, I would have > converted the hash table to an ordered list (ordered by the creation index, a > global entity atomically updated every time an attribute is created), and > proceed to destroy the attributed in the desired order. Thus instead of > having a linear operation for every operation on attributes, we only have a > single linear operation per communicator (and this during the destruction > stage). > > George. > > On Jan 16, 2013, at 16:37 , KAWASHIMA Takahiro <rivis.kawash...@nifty.com> > wrote: > > > Hi, > > > > I've implemented ticket #3123 "MPI-2.2: Ordering of attribution deletion > > callbacks on MPI_COMM_SELF". > > > > https://svn.open-mpi.org/trac/ompi/ticket/3123 > > > > As this ticket says, attributes had been stored in unordered hash. > > So I've replaced opal_hash_table_t with opal_list_t and made necessary > > modifications for it. And I've also fixed some multi-threaded concurrent > > (get|set|delete)_attr call issues. > > > > By this modification, following behavior changes are introduced. > > > > (A) MPI_(Comm|Type|Win)_(get|set|delete)_attr function may be slower > > for MPI objects that has many attributes attached. > > (B) When the user-defined delete callback function is called, the > > attribute is already removed from the list. In other words, > > if MPI_(Comm|Type|Win)_get_attr is called by the user-defined > > delete callback function for the same attribute key, it returns > > flag = false. > > (C) Even if the user-defined delete callback function returns non- > > MPI_SUCCESS value, the attribute is not reverted to the list. > > > > (A) is due to a sequential list search instead of a hash. See find_value > > function for its implementation. > > (B) and (C) are due to an atomic deletion of the attribute to allow > > multi-threaded concurrent (get|set|delete)_attr call in MPI_THREAD_MULTIPLE. > > See ompi_attr_delete function for its implementation. I think this does > > not matter because MPI standard doesn't specify behavior in such cases. > > > > The patch for Open MPI trunk is attached. If you like it, take in > > this patch. > > > > Though I'm a employee of a company, this is my independent and private > > work at my home. No intellectual property from my company. If needed, > > I'll sign to Individual Contributor License Agreement.
