[Gluster-devel] Improving thread synchronization in GlusterD

[Jeff Darcy]

> One important example of the kind of concurrency related issues is,
> 
> When a glusterd comes back up (or reconnects to the cluster), it receives
> information about the current view of cluster (crudely, the list of volumes
> and the list of peers) as seen by a peer, from all available peers.
> glusterd initiates the transition to the view provided by a peer while
> receiving
> 'newer' updates. As part of the transition to the 'newer' view glusterd
> destroys
> data structures associated with the 'older' view. If the 'older' view is in
> 'use',
> i.e if a thread is spawning a brick in the 'older' view, glusterd may crash
> (classic "use after free").
> 
> RCU's "copy and update" could be used to prevent premature freeing of data
> structures associated with the 'older view'. We expect the code changes to
> be lesser if we used RCU in comparison with other granular locking mechanism,
> where we would need to do a whole lot* by ourselves.
> 
> * - we need to make all our data structures that are shared to be
> ref-counted.
>   - we need to add code, nearly everywhere to ref-count properly. It is only
>     harder but not impossible.
> 
> Does that provide a better context to this proposal?


Yes.  Thank you.