<div dir="ltr"><br>I have a query why do we take a lock at the time of doing an operation in a dictionary.I have observed in testing it seems there is no codepath where<br>  we are using the dictionary parallel. In theory, the dictionary flow is like one xlator put some data in a dictionary and pass to the next xlator and xlator  and originator xlator won&#39;t touch dictionary until the called xlator returns.<br><br>  To prove the same I have executed below test case<br>  1) I have changed all LOCK/UNLOCK macro with dictlock/dictunlock function in the dictionary code and call the LOCK/UNLOCK macros<br>  2) Create a 1x3 volume and mount the volume<br>  3) Run stap script on one of the node to measure dict lock contention to log the entry if more than one thread access the dictionary at the same time<br>  4) Run smallfile tool like below with multiple operations like create/append/cleanup<br>     /root/sync.sh; python /root/smallfile/smallfile_cli.py --operation &lt;op_name&gt; --threads 8 --file-size 64 --files 5000 --top /mnt/test  --host-set &quot;<a href="http://hp-m300-2.gsslab.pnq.redhat.com">hp-m300-2.gsslab.pnq.redhat.com</a>&quot;;<br>  <br>   I have not found any single thread that is trying to access the dictionary while dictlock is already held by some other thread.<br><br>  I have uploaded a patch(<a href="https://review.gluster.org/#/c/glusterfs/+/23603/">https://review.gluster.org/#/c/glusterfs/+/23603/</a>) after converting the if condition to false in dictlock/unlock and run the <div>  regression test suite.I am not getting major failures after removing the lock from a dictionary.<br><br>  Please share your view on the same if the dictionary is not consumed by multiple threads at the same time still we do need to take lock <div>  in the dictionary.<br>  Please share if I need to test something more to validate the same.<br>  <br><div>Regards,</div><div>Mohit Agrawal</div></div></div></div>