Jeff, OK. I'll try implementing George's idea and then you can compare which one is simpler.
Regards, KAWASHIMA Takahiro > Not that I'm aware of; that would be great. > > Unlike George, however, I'm not concerned about converting to linear > operations for attributes. > > Attributes are not used often, but when they are: > > a) there aren't many of them (so a linear penalty is trivial) > b) they're expected to be low performance > > So if it makes the code simpler, I certainly don't mind linear operations. > > > > On Jan 17, 2013, at 9:32 AM, KAWASHIMA Takahiro <rivis.kawash...@nifty.com> > wrote: > > > 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.
