prov/util: Revert util_av, util_cq and util_cntr to mutex

Switch ep_list_lock to always be a mutex lock until we can agree on a
better long term decision. The issue is that some endpoints want the
ability to not require FI_THREAD_SAFE at the domain level, but they want
to be able to control the endpoint in a seperate thread.  The
ep_list_lock is used for both the data path, and the control path.  In
order to adhere to the current api, and not break providers that follow
the current api, we need to revert this lock to a mutex until we can get
a optimal solution for everyone.

Signed-off-by: Seth Zegelstein <szegel@amazon.com>

prov/util/src/util_av.c

@@ -552,9 +552,7 @@ int ofi_av_init_lightweight(struct util_domain *domain, const struct fi_av_attr
 	 */
 	av->context = context;
 	av->domain = domain;
-	ofi_genlock_init(&av->ep_list_lock,
-			 domain->threading == FI_THREAD_DOMAIN ?
-			       OFI_LOCK_NOOP : OFI_LOCK_MUTEX);
+	ofi_genlock_init(&av->ep_list_lock, OFI_LOCK_MUTEX);
 	dlist_init(&av->ep_list);
 	ofi_atomic_inc32(&domain->ref);
 	return 0;

prov/util/src/util_cq.c

@@ -707,7 +707,8 @@ int ofi_cq_init(const struct fi_provider *prov, struct fid_domain *domain,
 	if (ret)
 		goto destroy1;
 
-	ret = ofi_genlock_init(&cq->ep_list_lock, lock_type);
+	/* TODO Figure out how to optimize this lock for rdm and msg endpoints */
+	ret = ofi_genlock_init(&cq->ep_list_lock, OFI_LOCK_MUTEX);
 	if (ret)
 		return ret;
 

prov/util/src/util_ep.c

@@ -247,9 +247,8 @@ int ofi_endpoint_init(struct fid_domain *domain, const struct util_prov *util_pr
 	if (util_domain->eq)
 		ofi_ep_bind_eq(ep, util_domain->eq);
 
-	ret = ofi_genlock_init(&ep->lock,
-			       ep->domain->threading != FI_THREAD_SAFE ?
-			       OFI_LOCK_NOOP : OFI_LOCK_MUTEX);
+	/* TODO Figure out how to optimize this lock for rdm and msg endpoints */
+	ret = ofi_genlock_init(&ep->lock, OFI_LOCK_MUTEX);
 	if (ret)
 		return ret;