[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5 3/4] xenstore: rework of transaction handling
On Fri, Mar 31, 2017 at 03:47:58PM +0200, Juergen Gross wrote: > On 31/03/17 15:01, Wei Liu wrote: > > On Fri, Mar 31, 2017 at 02:11:46PM +0200, Juergen Gross wrote: > >> On 31/03/17 14:03, Wei Liu wrote: > >>> Another stupid question below. > >>> > >>> On Fri, Mar 31, 2017 at 01:29:19PM +0200, Juergen Gross wrote: > >>>> > >>>> -struct changed_node > >>>> +/* > >>>> + * Some notes regarding detection and handling of transaction conflicts: > >>>> + * > >>>> + * Basic source of reference is the 'generation' count. Each writing > >>>> access > >>>> + * (either normal write or in a transaction) to the tdb data base will > >>>> set > >>>> + * the node specific generation count to the global generation count. > >>>> + * For being able to identify a transaction the transaction specific > >>>> generation > >>>> + * count is initialized with the global generation count when starting > >>>> the > >>>> + * transaction. > >>>> + * Each time the global generation count is copied to either a node or a > >>>> + * transaction it is incremented. This ensures all nodes and/or > >>>> transactions > >>>> + * are having a unique generation count. > >>>> + * > >>>> + * Transaction conflicts are detected by checking the generation count > >>>> of all > >>>> + * nodes read in the transaction to match with the generation count in > >>>> the > >>>> + * global data base at the end of the transaction. Nodes which have been > >>>> + * modified in the transaction don't have to be checked to match even > >>>> if they > >>>> + * have been read, as the modified node will be globally visible after > >>>> the > >>>> + * succeeded transaction possibly overwriting another modification > >>>> which may > >>>> + * have occurred concurrent to the transaction. > >>>> + * > >>>> + * Examples: > >>>> + * --------- > >>>> + * The following notation is used: > >>>> + * I: initial state > >>>> + * G global generation count > >>>> + * g(X) generation count of node X > >>>> + * G(1) generation count of transaction 1 > >>>> + * g(1:Y) saved generation count of node Y in transaction 1 > >>> > >>> Assuming this is recorded in accessed_node, can you point me to where > >>> about in the code this is implemented? I looked at access_node but that > >>> only records generation for read. > >> > >> It is in the node itself stored in the data base. > >> > > > > Right, then ... > > > >>>> + * TA1: operation in transaction 1 > >>>> + * X=1:X replace global node X with transaction 1 specific value of X > >>>> + * > >>>> + * 1. Simple transaction doing: read node A, write node B > >>>> + * I: g(A) = 1, g(B) = 2, G = 3 > >>>> + * Start transaction 1: G(1) = 3, G = 4 > >>>> + * TA1: read node A: g(1:A) = 1 > >>>> + * TA1: write node B: g(1:B) = 4, G = 5 > >>> > > > > I suggest updating places like g(1:B) = 4 to g(B) = 4 to match the code. > > No, as during the transaction only the node with the transaction > prepended is being stored in the data base. It isn't visible outside > the transaction until the transaction has been committed. > Hmm... yes, that's true. > So the notation isn't reflecting where the generation count is stored, > but only that it is specific to the transaction/node pair. > OK. Wei. > > Juergen _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |