> 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. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
