> The Big-lock, in its current state, doesn’t even fully satisfy the > problem it set out to solve, and has more problems on top of that. > These problems are only going to grow with new features and new code > being added to GlusterD. What level of such change do we expect in the 3.x development stream? There are problems with glusterd that even reader-writer locks or RCU won't solve, which is why there's already work in progress toward a 4.x version. Perhaps it's selfish of me, but I'd like to see as much of our effort as possible directed toward the longer-term solution. Perhaps a more detailed list of problems we have or anticipate in 3.x would help us reason about how much effort there is justified. > The most obvious solution would be to split up the Big-lock into more > fine grained locks. We could go one step further and use replace the > mutex locks (Big-lock is a mutex lock), with readers-writer locks. > This will bring in more flexibility and fine grained control, at the > cost of additional overheads mainly in the complexity of > implementation. I agree that finer-grain locking is not the answer. Computing history is full of stories about reducing lock granularity only to find that the result is both slower and more prone to deadlock. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
