[Gluster-devel] Improving thread synchronization in GlusterD

[Jeff Darcy]

> 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.