\texttt{MPI_Info} provides a way to create a list of \texttt{(key,value)} pairs  where the \texttt{key} and \texttt{value} are both strings.  Because many routines, both  in the MPI implementation and in related APIs such as the BNR process  management interface, require \texttt{MPI_Info} arguments, we define a simple   structure for each \texttt{MPI_Info} element.  Elements are allocated by the   generic object allocator; the head element is always empty (no \texttt{key}  or \texttt{value} is defined on the head element).      The routines listed here assume that an info is just a linked list of   info items.  Another implementation would make \texttt{MPI_Info} an \texttt{MPID_List},  and hang \texttt{MPID_Info} records off of the list.  For simplicity, we have   not abstracted the info data structures; routines that want to work  with the linked list may do so directly.  Because the \texttt{MPI_Info} type is  a handle and not a pointer, MPIU (utility) routines are provided to handle  the allocation and deallocation of \texttt{MPID_Info} elements.\subsection{Thread Safety}  The info interface itself is not thread-robust.  In particular, the routines  \texttt{MPI_INFO_GET_NKEYS} and \texttt{MPI_INFO_GET_NTHKEY} assume that no other   thread modifies the info key.  (If the info routines had the concept  of a next value, they would not be thread safe.  As it stands, a user  must be careful if several threads have access to the same info object.)   Further, \texttt{MPI_INFO_DUP}, while not   explicitly advising implementers to be careful of one thread modifying the  \texttt{MPI_Info} structure while \texttt{MPI_INFO_DUP} is copying it, requires that the  operation take place in a thread-safe manner.  There isn\texttt{} much that we can do about these cases.  There are other cases  that must be handled.  In particular, multiple threads are allowed to   update the same info value.  Thus, all of the update routines must be thread  safe; the simple implementation used in the MPICH implementation uses locks.  Note that the \texttt{MPI_Info_delete} call does not need a lock; the defintion of  thread-safety means that any order of the calls functions correctly; since  it invalid either to delete the same \texttt{MPI_Info} twice or to modify an  \texttt{MPI_Info} that has been deleted, only one thread at a time can call   \texttt{MPI_Info_free} on any particular \texttt{MPI_Info} value.