dspaces_put_sync completes once the ss_obj_put rpc call has been received by the server. There is no dependency on the server having completed the RDMA read. This means that, for example, the test writer will release write lock before the server has received the written object. This seems to defeat the purpose of the sync call. I think this might be due to incorrect processing of work completion events; the client seems to update the sync lock on a message completion, rather than an RDMA completion. This may point to some more subtle issues in event processing with the Infiniband transport. I'm not sure if the issue is present on GNI transport yet.
(At least in the Infiniband transport)
dspaces_put_sync completes once the ss_obj_put rpc call has been received by the server. There is no dependency on the server having completed the RDMA read. This means that, for example, the test writer will release write lock before the server has received the written object. This seems to defeat the purpose of the sync call. I think this might be due to incorrect processing of work completion events; the client seems to update the sync lock on a message completion, rather than an RDMA completion. This may point to some more subtle issues in event processing with the Infiniband transport. I'm not sure if the issue is present on GNI transport yet.