WO2017095387A1 - Objet à valeurs simultanées multiples - Google Patents
Objet à valeurs simultanées multiples Download PDFInfo
- Publication number
- WO2017095387A1 WO2017095387A1 PCT/US2015/063051 US2015063051W WO2017095387A1 WO 2017095387 A1 WO2017095387 A1 WO 2017095387A1 US 2015063051 W US2015063051 W US 2015063051W WO 2017095387 A1 WO2017095387 A1 WO 2017095387A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- value
- view
- context
- isolation context
- isolation
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2308—Concurrency control
Definitions
- a computer system may have a memory that is shared by multiple computing entities (multiple threads, for example).
- the computing entities may concurrently perform computations that change the values that are stored in the shared memory.
- One way to control the concurrent processing by the computing entities is to organize the changes by the entities into transactions and atomically commit the transactions to memory in a manner that maintains the memory in a consistent state.
- Fig 1 A is a schematic diagram of a system according to an example implementation.
- Fig. 1 B is an illustration of data structures to manage multiple simultaneous value (MSV) objects according to an example implementation.
- FIG. 2 is an illustration of a hierarchical ordering of isolation contexts according to an example implementation.
- Fig. 3A illustrates the relationship of a parent isolation context and a live child isolation context created from the parent isolation context according to an example implementation.
- Fig. 3B illustrates the relationship of a parent isolation context and a snapshot child isolation context created from the parent isolation context according to an example implementation.
- Fig. 4 is a flow diagram illustrating a technique to determine an MSV object value associated with a view of a child isolation context according to an example implementation.
- FIG. 5 is a flow diagram illustrating a technique to postpone an effect of publishing on a view of an object having alternative values according to an example implementation.
- FIG. 6 is a flow diagram illustrating a technique to manage publication of an isolation context for multiple publication attempts according to an example
- Fig. 7 is a flow diagram illustrating a technique to control publication of an isolation context associated with an object having alternative values according to an example implementation.
- FIG. 8 illustrates a schematic diagram of a system of physical machines according to a further example implementation.
- Multiple threads executing in one or more processes of a computer or multiple computers may perform operations that are directed to one or multiple shared data structures.
- One approach to maintain a consistent state of the data structure is to block other threads from making changes to the data structure while one of the threads makes changes. This may, however, result in inefficient processing.
- Another approach to maintain a consistent state of the data structure is for the threads to process their changes as transactions, which are atomically committed to memory or rolled back (e.g., their modifications discarded) upon discovery that changes made by another thread conflict with the changes attempting to be committed.
- Such an approach may present challenges for relatively large
- transactions e.g., transactions that read or modify a large number of locations associated with the data structure or transactions that run for a long time before attempting to commit
- the probability that no other thread, during the course of the transaction's execution, made a modification that results in a conflict that prevents the commit attempt from being successful may be relatively small.
- a second attempt (and subsequent attempts) at redoing the changes following a rollback and retrying the committing the transaction may once again fail.
- an "isolation context” also called a “computational context” herein refers to an environment in which computations that are performed within the environment are contained within the environment so that the results of the computations are not, in general, visible to other isolation contexts. Due to the computational isolation, machine executable instructions, or program code, that is executing within the isolation contexts may concurrently make modifications to a data structure that is shared by the contexts.
- a "data structure” refers to an organization of one or multiple units of data, which are stored in one or multiple storage locations.
- an isolation context may be used to access (e.g., read or modify) multiple data structures.
- Each isolation context may present to program code a corresponding "view" of the data structure, where the "view” refers to the value(s) that the isolation context reads for corresponding properties of the data structure.
- a single isolation context may be associated with multiple views.
- a "property” may be a location associated with the data structure (e.g., a field within a record or an index of an array), a structural property of the data structure (e.g., a number of elements in a list), or a relationship that is associated with the data structure (e.g., an association of a value with a key in a map).
- properties of a data structure may be represented by multiple simultaneous value (MSV) objects.
- MSV object represents a property of a unit of data and may concurrently, or simultaneously, have multiple, alternative values.
- a particular logical location such as a field of a record or a slot in an array, may be represented by an MSV object, such that the field or slot has different, alternative values, when seen through different views.
- a given isolation context may be associated with one or multiple views that may be used when accessing one or multiple MSV objects. Moreover, multiple isolation contexts may be associated with multiple views of a given MSV object. The values associated with different views in a given MSV object may be isolated from each other. In this manner, as part of this isolation, a request to determine a value for the MSV object in a given view may result in the return of one of the MSV object's alternative values; and assigning the value of the MSV object in a given view may not affect the value of the MSV object in another view.
- isolation contexts create computational isolation, there are mechanisms by which an isolation context may transfer information to another isolation context.
- One way a first isolation context may transfer information to a second isolation context is for the first isolation context to publish.
- "Publishing" an isolation context refers to combining or merging the view of the publishing isolation context with the view of another isolation context so that the views are the same at the time of publication.
- a given publication attempt may not succeed due to one or multiple publication conflicts.
- a publication conflict also called a "conflict" herein refers to a reason for the publication not to occur.
- An example of a conflict is the existence a modification made to a data structure (e.g., a change to a field of a record) within the isolation context that is the target of the publication attempt when a similar modification (e.g., a change to the same field of the same record) was made within the isolation context being published or when a similar value (e.g., the value of the same field of the same record) was read within the isolation context being published and a modification to the same data structure or another data structure was made that may have been based on the value that was read.
- a similar modification e.g., a change to the same field of the same record
- any conflict(s) that cause a publication attempt to fail are identified; one or multiple actions are taken to resolve the conflict(s), including action(s) that involve making one or multiple modifications within the first isolation context; and then, publication subsequently occurs by allowing the second isolation context to view the modifications made by the first isolation context prior to the first publication attempt as well as the modification(s) made to resolve the conflict(s), as of the time that is associated with subsequent publication attempt.
- the isolation contexts may be fully hierarchical, and managing the MSV object may include determining a value for a particular view of the MSV object. This determination may include, for a view associated with a child isolation context, determining a value that is associated with the parent's view of the child's view.
- managing an MSV object may include using a lazy process to publish an isolation context associated with the MSV object, in which effects of the publishing on one or multiple views of the MSV object may be deferred until an operation (e.g., read or write operation) on the MSV object occurs after the publication.
- an operation e.g., read or write operation
- a processor-based system 100 includes a data management engine 140, which manages the reading and modification of one or multiple data structures 106.
- the data management engine 140 may be formed from one or multiple operating system processes that execute one or multiple threads.
- the data management engine 140 includes context and MSV object management resources 130 and isolation contexts 1 10 (N isolation contexts 1 10-1 , 1 10-2...1 10-N being depicted in Fig. 1A).
- the data management engine 140 uses the resources 130 for such purposes as creating and terminating isolation contexts 1 10; managing publications by the isolation contexts 1 10; and managing MSV objects.
- a given property of a data structure 106 may be represented by an MSV object; and the MSV object may have multiple, alternative values, depending on a view 120 specified when accessing the MSV object. In this manner, the value of the MSV object is seen in, or through, a particular view 120.
- an isolation context is a mechanism by which executing machine executable instructions (called “program code 1 12," herein) may isolate itself from other executing program code 1 12.
- the program code 1 12 may be an entire application or program or may be part of such an application or program, such as a thread.
- program code 1 12 may be working in a prevailing (also referred to herein as the "current" or “working") isolation context 1 10.
- program code 1 12-1 may be working in a prevailing isolation context 1 10-1 .
- each thread may have its own prevailing isolation context 1 10, and different threads executing program code 1 12 at the same time may be working in different prevailing isolation contexts 1 10.
- the prevailing isolation context 1 10 in the child thread when it begins executing is that of the parent thread (e.g., at the time the child thread was created).
- References herein to program code 1 12 "executing in" a given isolation context 1 10 refer to the program code 1 12 executing while the given isolation context 1 10 is the prevailing isolation context.
- a sequence of machine executable instructions (called “thread A” for this example) of program code 1 12 may be executing in one of the isolation contexts 1 10, and another sequence of machine executable instructions (called “thread B” for this example) of program code 1 12 may be executing in another one of the isolation contexts 1 10.
- threads A and B may share a data structure 106.
- changes made to data by thread A to the data structure 106 may be invisible to thread B, and changes made to the data structure 106 by thread B may be invisible to thread A. That is, different computations, working at the same time and looking at the same fields of the same records, may correctly see different values.
- each isolation context 1 10 has an associated view 120 (or multiple views 120) to a given data structure 106; and as such, multiple isolation contexts 1 10 may have different associated views 120 of the same data structure 106.
- Multiple operating system threads may work in the same isolation context 1 10, in accordance with example implementations.
- the multiple operating system threads may be associated with multiple operating system processes and the multiple operating system processes may be associated with multiple computers. This allows sharing of the same view 120 among multiple processes and computers. Moreover, this arrangement allows processes that share an isolation context 1 10 to be written in different programming languages.
- the data structures 106 may be stored in a data store 104.
- the data store 104 may be stored in a physical storage device (a volatile or non-volatile memory device, a hard disk device, and so forth) or may be stored across a distributed arrangement of physical storage devices.
- a "data structure 106" refers to any unit of data that may be stored. Examples of data structures 106 include files, records, lists, sets, maps, tables, arrays, strings, queues, stacks, graphs, directories, primitives (a number, a Boolean value, a character, as examples), and so forth.
- a data structure 106 may also include a data structure included by reference (e.g., a pointer).
- the resources 130 may include one or multiple libraries 134, with each library 134 including one or multiple functions 136 that may be called by the program code 1 12 for such purposes as creating isolation contexts, establishing views for isolation contexts, binding functions to isolation contexts, identifying conflicts, resolving conflicts, publishing contexts, as so forth, as further described herein.
- the management resources 130 may contain one or multiple data structures 150, which may also be used for purposes of creating, maintaining, and managing the isolation contexts 1 10 and MSV objects 106, as described herein.
- the isolation contexts 1 10 are fully hierarchical, as illustrated by an example hierarchical tree 200. In this manner, multiple isolation contexts 1 10 may form a tree that is rooted at a top-level, global isolation context 1 10, and a given isolation context 1 10 may have any number of children. For the example of Fig.
- isolation context 1 10-3 is a global context that is a parent of isolation contexts 1 10-4 and 1 10-5 and grandparent of isolations contexts 1 10-6 and 1 10-7; isolation contexts 1 10-4 and 1 10-5 are siblings; isolation contexts 1 10-6 and 1 10-7 are children of parent isolation context 1 10-4; and isolation contexts 1 10-6 and 1 10-7 are siblings.
- the isolation context hierarchy may extend to any depth.
- isolation context 1 10 One way for information to travel from one isolation context 1 10 to another isolation context 1 10 is for a child isolation context 1 10 to successfully publish, thereby making the changes visible in the parent isolation context 1 10.
- isolation context P is a parent of isolation context C
- changes made within isolation context P are generally visible in the isolation context C, but changes made in the isolation context C are not visible in the isolation context P until the isolation context C is successfully published.
- the child isolation context 1 10 may have two forms, which are specified when the child isolation context 1 10 is created: a transparent, or live, isolation context; and an opaque, or snapshot isolation context.
- a live child isolation context such as example live child isolation context 1 10-9 of Fig. 3A
- changes made to a location L such as location 304 in Fig. 3A
- parent such as isolation context 1 10-8 of Fig. 3A
- the changes made in the parent isolation context may actually be changes that are made to an ancestor of the parent isolation context but are visible in the parent isolation context; and the changes may be due to a different child isolation context of the parent isolation context publishing its changes to the parent isolation context.
- a snapshot child isolation context such as example snapshot child isolation context 1 10-1 1 of Fig. 3B
- no changes that are made in the parent isolation context such as parent isolation context 1 10-10 of Fig. 3B
- the snapshot child isolation context is created are visible within the child isolation context.
- a live child isolation context C Within a live child isolation context C, reads made on locations that have not been modified in the context C return, as stated above, the value that the location would have had, had the read been made in the parent isolation context P. Either at the time of the read or by setting a default (at or after the time isolation context C was created or as a general policy in the process), the read may be specified as being "frozen.” A frozen read has the property that, once it occurs, all subsequent reads of that location within isolation context C (frozen or not) return the same value until the location is modified within isolation context C or until isolation context C is successfully published.
- the data management engine 140 may determine a value as of a current time. More generally, to determine an established value of the MSV object as of a given time (e.g., a request time), the data management engine 140 may attempt to determine whether a value associated with the property had been established (i.e., previously determined) in the view 120 prior to the request time and subsequent to the later of the time that the isolation context 1 10 was created or the time the isolation context 1 10 was last successfully published prior to the request time.
- a value associated with the property i.e., previously determined
- Such a value may have been established by modifications to the property by program code 1 12 executing in the isolation context 1 10, by frozen reads to the property by program code 1 12 executing the isolation context 1 10, or by successful publication of a value for the property from a child isolation context 1 10 of the isolation context 1 10. If such a value was established, then it is the determined value. Otherwise, the determined value may be found by determining an inherited value for the property, where the inherited value is the value associated with the property within a parent view 120 of the view 120 associated with the parent isolation context 1 10 of the isolation context 1 10 as of an effective time based on the view 120 and the request time. As an example, when the isolation context 1 10 associated with the view 120 is a live (i.e.
- the effective time may be the request time.
- the isolation context 1 10 associated with the view 120 is a snapshot isolation context 1 10
- the effective time may be the later of the creation time of the snapshot isolation context 1 10 and a time associated with the latest successful publication of the snapshot isolation context 1 10 prior to the request time.
- a technique 400 includes associating (block 404) a plurality of views with a plurality of alternative values for an object and associating (block 408) a plurality of
- the computational contexts include a parent computational context and a child computational context that is derived from a parent computational context.
- the views are isolated from each other. In this manner, as part of this isolation, a request to determine a value for the in a given view results the return of one of the object's alternative values; and assigning the value of the object in a given view does not affect the value of the object in another view.
- the child computational context is published (block 416).
- a request to determine a value associated with a first view that is associated with the child computational may be received, pursuant to block 420.
- a deternnination is made (block 424) whether a value has been associated with the first view subsequent to the publication of the child computational context; and in response to the determination, a value associated with a parent view of the first view associated with the parent computational context is selectively determined, pursuant to block 428.
- an isolation context 1 10 may invoke a call operation, which takes a function 136 (see Fig. 1A) as an argument (and perhaps takes other arguments to pass to the function), temporarily sets the prevailing isolation context to another context, runs the function 136, and returns the result.
- the result of the call operation remains the value as it appears in the invoked isolation context 1 10.
- the count may have had a value of "10,” but calling the function f sets the count to 20.
- the two variables r and x refer to the same record, but the view presented through the variable r is that of the isolation context C, while the view presented through the variable x is that of the isolation context D.
- r.getCountQ continues to return "10,” but x.getCount() returns "20.” And if something elsewhere caused a computation in the isolation context D to set the count on the same record r to 30, further evaluation in the isolation context C causes x.getCount() to return "30.”
- the view presented through the variable x is neither that of isolation context C nor isolation context D but a composite "C's view of D's view" associated with isolation context C. If, within isolation context C, the count of the record accessed via x is either modified or accessed via a frozen read, subsequent reads of the count in the isolation context C via variable x result in the value established within isolation context C and ignore any intervening modifications made within isolation context D. This distinction remains until isolation context C is successfully published, at which point D's view and C's view of D's view are again identical. In this way, an isolation context may have multiple associated views 120.
- program code in an isolation context 1 10 may also bind a function to an isolation context (e.g., the prevailing isolation context 1 10 or a different isolation context 1 10), returning a new function 136 which, when invoked, runs the original function 136 in the bound isolation context 1 10 (e.g., by invoking the call operation on the bound context and passing in the original function 136 as a parameter).
- This binding operation may be used to create a function 136 that is bound to the current isolation context 1 10 and that can be invoked in a child isolation context 1 10 (or another isolation context 1 10 via the call operation).
- the binding operation may be used to create several new functions by the same function 136 to a number of different contexts 1 10.
- These multiple isolation contexts 1 10 may be snapshot contexts 1 10 representing the state of the world at various times in the past (e.g., snapshots of a company taken at daily intervals). Alternatively, these multiple isolation contexts 1 10 may be child isolation contexts 1 10 used to explore and select among different alternative approaches to solving a problem. A function bound to the current isolation context 1 10 may be provided to a different context (e.g., by the call operation) to allow the different context to observe and store data in the bound isolation context 1 10.
- Child isolation contexts 1 10 can obtain references to their parent isolation contexts 1 10, so even if there has been a modification or frozen read in a given child isolation context 1 10, the program code 1 12 of a child isolation context 1 10 may, in accordance with example implementations, invoke the call operation on its parent isolation context 1 10 to determine what the value of a particular location is in the view 120 of the parent isolation context 1 10. For example, to obtain the count field of a record "r" as it would be seen in the parent isolation context 1 10 of the current isolation context 1 10, a program written in Java might call: lsolationContext.current().parent().call(() -> r.getCount())
- a function may be called on the global isolation context 100, for example: lsolationContext.global().call(() -> revenue) to obtain the committed value of a variable.
- lsolationContext.global().call(() -> revenue) to obtain the committed value of a variable.
- such a call may be used to set a default value that is seen by code working in unpublished isolation contexts 1 10.
- Similar manipulations via the global isolation context 1 10 may be used to manipulate the namespace in a committed manner from within an unpublished isolation context.
- isolation contexts 1 10 may pass out values without publishing modifications, such values may be accumulated.
- program code 1 12 executing in an isolation context 1 10 may take a snapshot of the state of a company database periodically (e.g., every day, hour, minute or second) and make each of these snapshots available by binding the snapshots to names within a namespace.
- the executing program code 1 12 may append the snapshots to a single list, facilitating, for example, identifying the states of the database for the ten days that scored highest on some metric (e.g., the days during which the revenue of the company was highest).
- program code 1 12 executing in an isolation context 1 10 may run, in parallel child isolation contexts 1 10, a series of potential modifications according to models with different parameters, and place the results (indicating predicted consequences) computed in each child isolation context 1 10 (along with parameters used with the respective models) in a single structure. Then, all of the results may be compared with one another and the child isolation context 1 10 that resulted in the best (and only the best) outcome allowed to publish its results.
- program code 1 12 executing in an isolation context 1 10 may run, in parallel child isolation contexts 1 10, a series of non-deterministic simulations and collect the results produced within each simulation into a structure, and analyze the structure to determine, based on the results, an action to take.
- the child isolation contexts 1 10 may be allowed to terminate without ever publishing their modifications to their parent isolation contexts 1 10.
- program code 1 12 may execute code 1 12 in an arbitrary isolation context 1 10 by explicitly changing the prevailing isolation context 1 10 to be the arbitrary isolation context 1 10.
- Such a change may be temporary and bounded to particular region of code 1 12 (e.g., a particular function or program block) by ensuring that at the end of the region of code 1 12 the prevailing isolation context is reverted to what it had been before the change.
- isolation contexts control some, but not all variables or other memory locations available to the program. For such
- program code 1 12 executing in the temporary prevailing isolation context 1 10 may obtain a value, such as a reference to a data structure, where the reference is associated with a view 120 associated with the temporary prevailing isolation context 1 10, and may store that value in a location that is not under control of the isolation contexts.
- program code executing in the former prevailing isolation context 1 10 may obtain the value associated with the view 120 associated with the temporary prevailing isolation context 1 10.
- isolation contexts 1 10 Another way that information may move between isolation contexts 1 10 is when a child isolation context 1 10 publishes its
- the program may specify, when an isolation context 1 10 is created, that the isolation context 1 10 is "detached," which means that the isolation context 1 10 may not be published.
- An error may be signaled (e.g., an exception may be thrown) if an attempt is made to publish a detached isolation context 1 10.
- a conflict may be associated with a property associated with a data structure, where a property may be a location (e.g., a particular field of a particular record or a particular index of a particular array), a relationship managed by the data structure (e.g., the value associated with a particular key in a particular map), or a structural property of the data structure (e.g., the order of elements of a particular list or the number of elements contained in a particular set).
- a conflict may arise due to the existence of an unpublished value associated with the view associated with the publishing isolation context, and a conflict arise due to the existence of an
- An unpublished value may be a value asserted to be associated with a view that has not yet been processed in response to a publication of an isolation context associated with the view. More specifically, a conflict may arise when the value associated with such a property is changed within the parent isolation context 1 10 of the isolation context 1 10 requesting publication.
- a conflict may arise when a new value otherwise becomes visible in the parent isolation context 1 10, when such a value change occurs after a particular effective time and when the child (e.g., publishing) isolation context either modified the same property (where such modification includes receiving a value due to the successful publication by a further child isolation context 1 10 of the publishing isolation context 1 10) or when the publishing isolation context performs a frozen read operation to obtain a value associated with the property.
- the effective time associated with a property relative to the publishing isolation context 1 10 may be established and updated upon creation of the publishing isolation context 1 10, each time the publishing isolation context 1 10 is successfully published, and upon an explicit indication (e.g., during an attempt to resolve conflicts due to an unsuccessful publication attempt) by program code 1 12 executing in the publishing isolation context 1 10 that any conflicts associated with the property have been resolved.
- the effective time may be updated when the publishing isolation context 1 10 is established as the prevailing isolation context 1 10.
- the effective time is also updated the first time a modification to or frozen read of the property is performed following such a creation, successful publication, or explicit indication.
- an "atomic" process means that the actions that form the process are treated as being indivisible, i.e., the actions are viewed or treated by the isolation contexts as occurring at the same time.
- a thread cannot see some, but not all, of the published modifications in the parent isolation context, and a modification cannot be made in any isolation context that would change the determination that there are no conflicts, between the determination that there are no conflicts and the making available of the
- the conflict(s) may be determined proactively so that the conflicts are known at the time the isolation context 1 10 requests publication.
- the isolation context 1 10 and its parent isolation context 1 10 present the same values for the data structure 106, and the child isolation context 1 10 is no longer considered to have established any current values for the data structure 106. As described above, attempts to determine values for properties of the data structure 106 within the child isolation context 1 10 results in determining inherited values from the parent isolation context 1 10.
- a live isolation context 1 10 this has the effect that locations that had been "frozen” by modifications or by frozen reads are no longer considered frozen and the inherited values may vary as modifications are made to the parent context; and for a snapshot isolation context 1 10, the "snapshot time" (i.e., the effective time used to find inherited values from the parent isolation context 1 10) is updated to the publication time.
- a last-common-snapshot for a given isolation context 1 10 may be obtained by calling the appropriate function 136.
- the last-common-snapshot is a read-only snapshot child of the context's parent as of the last time the isolation context 1 10 was published (or its creation time if it has not been published).
- an isolation context 1 10 to compare its changes to a data structure 106 with the values of the data structure 106 when the isolation context 1 10 started or was last successfully published.
- an as-created-snapshot for a given isolation context 1 10 (a snapshot going back to the beginning, or creation, of the snapshot) may be obtained by calling the appropriate function 136.
- a conflict resolution phase is entered for purposes of taking one or multiple actions to resolve the conflicts.
- the conflict resolution phase may be handled in a number of different ways, depending on the particular implementation.
- the program code 1 12 associated with the isolation context 1 10 attempting publication decides how to handle the conflicts and may decide to re-attempt the publication.
- the program code 1 12 marks each conflict as being resolved so that the conflict does not show up again for a subsequent publication attempt.
- a given conflict may be resolved by modifying a value of the property associated with the conflict and specifying that such a modification resolves any conflict for that property.
- the modification may be made by computing and setting a specific value.
- the modification may be one of the following.
- the modification may be a resolve-to-current modification in which the value in the publishing context is the one that is used. This is often the correct answer when it can be determined that the value asserted by the child isolation context 1 10 is not dependent on any conflicted value (i.e., if the program code 1 12 of the publishing isolation context 1 10 was executed again, the same result would occur).
- the modification may be a resolve-to- parent modification in which the current value in the parent isolation context 1 10 is the one that is used.
- the modification may be a roll-back modification in which the value in the last common snapshot is the one that is used.
- determining a value for a property associated with a data structure includes determining a lack of an
- the effective time may be the request time; and identifying the conflict includes
- the effective time may be the latter of a creation time of the first isolation context and a publication time of the first isolation context prior to the request time; and identifying the conflict includes identifying a conflict associated with the property due to the establishment of a value associated with the property in the parent's view subsequent to the latter of the creation time of the first isolation context and the latest publication time of the first isolation context.
- marking a conflict as being resolved may cause the system to disregard any known conflict associated with the location and the isolation context 1 10, but one or multiple subsequent modifications in the parent or child isolation contexts 1 10 may introduce one or multiple new conflicts, which arise when the isolation context 1 10 tries again to publish.
- program code 1 12 performing conflict resolution may make use of the current (e.g., publishing) isolation context 1 10, the parent isolation context 1 10, and the isolation context's 1 10 last-common-snapshot isolation context 1 10.
- the program code 1 12 may also make use of a current-at-publish isolation context 1 10 and a parent-at-publish isolation context 1 10, which are read-only snapshots of the current (publishing) context and its parent at the time the publication was attempted (and failed).
- one or multiple mechanisms may be used to encapsulate the process of creating an isolation context 1 10 as a child of the prevailing isolation context 1 10; running the code in it, and (when the created isolation context 1 10 is publishable) attempting to publish the created isolation context 1 10 at the end.
- the mechanism may involve keywords, annotations, or other syntactic additions to the source code of the program and the program code may be specified directly.
- the mechanism may involve calling a function (e.g., one of the functions 136 of Fig. 1 ) and passing as an argument an indication of a function to be called within the newly created isolation context 1 10.
- the program code 1 12 may specify (e.g., by choice of keyword, annotation, or function or by passing in a parameter) the type of child isolation context 1 10 to create (e.g., live or snapshot, detached or not, read-only or not).
- the program code 1 12 may further specify information used to control behavior upon failure of an attempt to publish. Such information may cause the system to attempt conflict resolution and may control the manner in which conflict resolution is performed. The information may alternatively or in addition direct the system to react to a failure to publish or a failure to resolve conflicts by creating a new child isolation context 1 10 and rerunning the code within it.
- the information may include one or more termination conditions, which the system may use to determine that further attempts to perform conflict resolution or to rerun the code should not occur.
- termination conditions may include a given number of attempts having been performed, a given time (e.g., a wall clock time or a time duration) having been passed, a given amount of a resource (e.g., disk space or memory) having been consumed, a value having been asserted by another program thread (e.g., an indication that a solution to a problem has been found by another thread or an indication that a program has gone on to a different phase), a given function returning a true value, a Boolean
- the conflict resolution may be handled in a number of different ways.
- the program code 1 12 may decide that resolving the conflict is not worth the effort, and as a result, the isolation context 1 10 does not attempt to republish.
- the program code 1 12 may be relatively small (online transaction processing (OLTP) code, for example); and as such, the approach may be to simply throw away the associated isolation context 1 10, create a new isolation context 1 10 and execute the program code 1 12 again from the beginning.
- OLTP online transaction processing
- the conflict resolution may be handled by an object or by a function 136 (see Fig. 1A) that is designated as a conflict resolver at the time the code 1 12 modified the location that was conflicted, such designation indicating that should a conflict be detected associated with this location and value, the object or function should be invoked to resolve the conflict.
- the program code 1 12 may specify a default resolver (e.g., an object or function) that is associated with a particular location (e.g., a particular field in a particular record), with a particular field (regardless of what record a conflict occurs in), or a type (e.g., applying to conflicts associated with any property of any data structure as long as the property is associated with values of the given type or applying to conflicts associated with any field of any record as long as the record is of the given type).
- a default resolver e.g., an object or function
- a particular location e.g., a particular field in a particular record
- a particular field regardless of what record a conflict occurs in
- a type e.g., applying to conflicts associated with any property of any data structure as long as the property is associated with values of the given type or applying to conflicts associated with any field of any record as long as the record is of the given type.
- This type of conflict resolution may be appropriate when a field is, for example, known to be used
- a resolver may be attached to the field to perform this computation and resolve the conflict by specifying the resulting value.
- the program code 1 12 may use task-based conflict resolution.
- task-based conflict resolution the program code 1 12 specifies that some or all of its computation is made up of re-runnable tasks that are executed by the program code 1 12.
- the data management engine 140 may keep track of the set of locations read and written while working in each task and the dependencies between tasks (e.g., a dependency create where one task reads a location that was written by another task).
- the program code 1 12 may provide a function that takes a collection of conflict objects and runs arbitrary code to determine how to resolve the conflicts explicitly.
- the program code 1 12 may use a combination of the above-described approaches, even for a single publication attempt.
- the program code 1 12 may use field-based rules to resolve (and eliminate) some conflicts and then invoke one or multiple functions, objects and/or tasks to resolve the remaining conflicts.
- a technique 500 includes providing (block 504) a multiple simultaneous value object having an associated first set of values associated with a first view, which is associated with a first computational context of a processor-based machine.
- the object also has an associated second set of values associated with a second view, which is associated with a second computational context of the processor-based machine.
- the technique 500 includes attempting to publish the second computational context, pursuant to block 508; and prior to the publishing attempt, detecting a publication conflict, pursuant to block 512.
- Pursuant to the technique 500 in response to the publication attempt, publication of the second computational context is controlled (block 516) based at least in part on the detected publication conflict.
- a technique 630 includes executing (block 634) machine executable instructions in a processor-based machine in a first isolation context and in a second isolation context.
- the first isolation context presents an associated first view of a data structure
- the second isolation context presents and associated second view of the data structure.
- Executing the machine executable instructions includes inhibiting (preventing, for example) modifications that are made to the first object in the first isolation context from being reflected in the second view.
- a modification made in the first view "being reflected" in the second view refers to the modification being reproduced or shown in the second view.
- an attempt is made (block 638) to publish the first isolation context to reflect modifications made to the data structure in the first isolation in the second view of the data structure. If a determination is made
- the technique 630 includes publishing (block 650) the first isolation context, including causing the second view to reflect modifications made to the data structure within the first isolation context. These modifications include modifications made during action(s) taken to resolve conflict(s), as of a time associated with the last attempted publication attempt.
- the data management engine 140 may use various data structures 150 to manage the MSV objects.
- a given data structure150 may be an object represented by a C++ class.
- the data structures 150 may include isolation context objects 151 .
- Each isolation context object 151 corresponds to one of the isolation contexts 1 10. It is noted that in the following discussion, "isolation context object 151 " and “isolation context 1 10" may be used interchangeably.
- Conflicts 152 that prevent publication of the isolation context 1 10 may be installed on a corresponding isolation context state 157.
- the data structures 150 may include view objects 153.
- Each view object 153 may correspond to one of the views 120. It is noted that in the following discussion, “view object 153" and “view 120” may be used interchangeably.
- the data structures 150 may include one or multiple conflict generators 160.
- a conflict generator 160 may construct conflicts referring to a particular location.
- Each subtype of conflict may have its own generator subtype, in
- the data structures 150 may include context states 157.
- a context state 157 represents the current set of conflicts and "contingent conflicts" for an associated isolation context 1 10, as well as a count or event time, representing the last time the isolation context associated with the conflict successfully published.
- the data structures 150 may include an event counter 164, which may represent a monotonically-increasing set of values that are incremented by particular events.
- the event counter 164 may represent a global, shared event count, which is atomically incremented.
- the constant representing the greatest possible value of an event counter may be used to represent the most recent event count.
- values of the event counter 164 may be associated with snapshot creation times, in accordance with example implementations. Values read from the event counter 164 may be considered to be timestamps denoting points in type of the execution of system 100, and the value stored in the event counter 164 may be considered to be the current time (or timestamp) of the system 100 with respect to the context and MSV object management resources 130. It is noted that save that their values monotonically increase over time, meaning that timestamps may be compared with one another, these timestamps have no necessary relationship with any other notion of time (e.g. wall-clock time or time since the start of an operating system or process in system 100). It is also noted that different reads of the event counter 164 may correctly read the same timestamp value, but consecutive reads of the event counter 164 may never read an earlier timestamp after reading a later timestamp.
- the data structures 150 may represent value chains 156, value objects 158 and MSV objects 166.
- Each value chain 156 may be associated with a particular view object 153 (representing a view 120) that may be use when accessing an MSV object 166; and the value chain 156 represents a history of value objects 158 (for a particular MSV object 166 noted in the given view 120), starting from the most recently asserted and extending in a time ordered sequence back in time.
- each value object 158 may contain a value (e.g., a primitive value or a reference to a data structure) for the MSV object 166 in the view 120 associated with the value chain 156 valid as of a particular timestamp, a timestamp representing that effective time and a link to a prior value object 158 (if any) for the same view 120.
- the data structures 150 may also include view relative pointers 154.
- a view relative pointer 154 represents a reference, or pointer, to a structured object (a record, array or a map, as examples) and also specifies that read and write accesses to the structured object are to be seen through the perspective of an associated view 120.
- the view relative pointer 154 may contain a pointer to an object and a pointer to a view object 153.
- the value stored in a value object 158 may be a view relative pointer 154.
- the view object 154 contained within a view relative pointer 154 stored in a value object 158 on a value chain 156 may be constrained to represent a view 120 associated with the same isolation context 1 10 that is associated with the value chain's 156 view 120.
- a given MSV object 166 represents alternative values for a property of a data structure 106, as seen through different views 120.
- the data structures 150 may also include MSV states 162.
- Each MSV state 162 represents the current set of one or multiple value chains 156, which may be associated with an associated MSV object 166.
- a given MSV object 166 may constrain the values associated with it to all be of a given type (e.g., all integers, all strings, or all lists of employee records).
- a given MSV object 166 may permit values of different types to be associated with it.
- the data structures 150 may also include MSV states 162.
- Each MSV state 162 may represent a set of value chains 156 associated with an MSV object 166.
- the data structures 150 may also include serializing tasks 170.
- the tasks 170 may include write or publication tasks, used to effect either a modification of an MSV object 166 (for a write task) or an attempt to publish an isolation context object 151 (for a publication task). These tasks 170 may be used to ensure that operations that are supposed to be atomic are, in fact, atomic, as simultaneous execution might cause incorrect behavior. Rather than blocking, the serialization of the tasks 170 may allow threads to cooperate with each other, as further described herein.
- the system 100 may use C++ atomic classes and associated functions, such as a C++ compare_exchange operation (also called a "compare and swap” operation or "CAS" operation).
- C++ compare_exchange operation also called a "compare and swap” operation or "CAS” operation.
- versioned pointers may be used, which encapsulate a value along with a version number, which is incremented every time the value is modified.
- the version number may be represented by the use of sequences of bits (e.g., high-order bits) within the versioned pointer value.
- Pointers, including versioned pointers, may encapsulate flags representing Boolean values (e.g., represented as bits within the pointer value).
- Operations performed on a data structure may be considered 150 to be logically atomic even though the performance of the operations takes measurable time, during which other operations involving the same data structure 150 may be initiated in another thread.
- a logical atomic operation that is associated with a finite processing time may be deemed to be correct when the result returned by the operation is one that would have been correct had the operation been instantaneous and executed at some arbitrary time in between the time the operation started and the time the operation finished and, further, when any modifications the made in the course of performing the operation may be logically ordered as a group with respect to those of other logically atomic operations. It is noted that this standard of correctness may be sufficient to guarantee that no sequence of operations performed in other threads is able to determine that the operation was not performed atomically.
- each modifiable location may be associated with an MSV object 166; each MSV object 166 may have an associated mapping from view objects 153 to value chains 156 (e.g., in an
- each value chain 156 may have an associated timestamped list of value objects 158.
- the mapping may distinguish between open view objects 153 and closed view objects 153. In accordance with example implementations, the mapping may distinguish between open and closed value chains 156 or views 120 associated with such view objects 153.
- An open view object 153 is a view object 153 whose associated value chain 156 was last modified (e.g., by the addition of a value object 158) subsequent to the last time that the isolation context 1 10 associated with the view object 153 (representing a view 120) was published prior to the creation of the MSV state 162 (although the isolation context 1 10 may have been subsequently published).
- a closed view object 153 is a view object 153 whose associated isolation context 1 10 is known to have been published since the last time its associated value chain 156 was modified.
- open view objects 153 associated with the MSV object 166 whose isolation contexts 1 10 (as represented by isolation context objects 151 ) have been published may be closed before the read or modification occurs. More specifically, in accordance with example implementations, an open view object 153 may be closed by a close_published_views process. In this process, a new value object 158 may be added to the value chain 156 associated with view object 153 that is the parent of the view object being closed (e.g., as the head of the value chain 156).
- the value in the new value object 158 may be the value from the most recent (e.g., first) value object 158 of the value chain 156 associated with the open view object 153, and the timestamp of the new value object 158 may be a timestamp associated with the successful publication of the view object's 153 isolation context 1 10.
- any view objects 153 to be closed by the close published views operations e.g., if there are any view objects 153 whose associated isolation contexts 1 10 have been successfully published since the last time a value object 158 was added to the respective value chain 156
- the close published views operation may be retried until a new MSV state 162 is successfully installed or a determination is made that there are no open view objects 158 in the MSV object's 166 current MSV state 162. In this manner, the value chains 156 are shared, and the threads cooperate with each other, as further described herein. All subsequent operations are done relative to the resulting MSV state 162, even if the MSV's 166 state 162 is changed again before the operation finishes. [0078] In accordance with example implementations, read and modify operations provided by MSV objects 166 may take as a parameter a view object 153
- the view object 153 may be that associated with the view relative reference 154.
- the operations may additionally take as a parameter an isolation context object 151 representing a prevailing isolation context 1 10.
- the isolation context object 151 may be requested to identify a shadow view object 153 for the provided view object 153, as described further below, and that shadow view object 153 may be used in place of the provided view object 153 in performing the operation.
- Read operations find the value chain 156, if any, associated with the view object 153 in the MSV state 162 and return the value from the value object 158 in the value chain 156 where the timestamp of the value object 158 is no later than a specified timestamp and is the latest such timestamp among the value objects 158.
- a "most recent" timestamp may be specified for the read operation, which indicates that the value object 158 with the most recent timestamp is to be used. If the timestamp is the "most recent" timestamp, the search for associated value chains 156 may be restricted to the open value chains 156 in the MSV state 162.
- the process is repeated, with the view object 158 being replaced by that view object's 158 parent view object (if any).
- the isolation context 1 10 associated with the replaced view object 153 is a snapshot isolation context 1 10
- the timestamp is replaced by the snapshot time for the isolation context 1 10 (e.g., the timestamp associated with the last successful publication of the isolation context 1 10 or the creation of the isolation context). This may continue until a value object 158 is found and its value is returned or until a view object 153 is determined to not have a parent. In this case, a default value of the appropriate type may be returned.
- a lazy publication process may be used to effect propagating changes made to an MSV object 166 in a given view 120 due to the publishing of an isolation context 1 10 associated with the view.
- operations that are directed to effecting the publication do not occur until a subsequent operation directed to the MSV object.
- a technique 700 includes providing (block 704) an object that has a plurality of alternative values; associating (block 708) a plurality of views with the plurality of alternative values; and associating (block 708) a plurality of computational contexts with the views.
- the views are isolated (block 712) such that a request to determine a value in a given view results in a value of the plurality alternative values being returned, and a first value associated with a first view is independent from association of a second value a second view.
- the technique 700 includes publishing (block 716) a computational context of the plurality of computational contexts to allow a value of the plurality of alternative values associated with a view of the plurality of views associated with the published context to be read in at least one other of the views; and in response to an operation directed to the object after the publishing, processing an effect of the publishing on the at least one other views, pursuant to block 720.
- operations that modify values associated with views 120 an MSV object 166 may be serialized by means of write tasks associated with the MSV object 166. These write tasks are represented by corresponding write task objects 170 (also called "write tasks 170" herein). For example, such operations may include writing a value, incrementing or otherwise modifying a value, or resolving a conflict associated with a value. To effect this serialization, the MSV object 166 may have the capability to be associated with a single pending write task 170.
- a thread of the data management engine 140 may create a write task object 170 to store the data required to perform the requested modification and to discover any conflicts that result from the modification. This data may be stored in the write task object 170, such that values determined by one thread performing the write task for the MSV object 166 may be visible to other threads performing the write task for the same MSV object 166.
- the write task object 170 may also contain information about steps in the process that have been completed by some thread. This may allow a given thread performing the write task to skip steps that have already been completed by another thread.
- the thread performing the modification may attempt to change the pending write task associated with the MSV object 166 from a null value to the newly created write task object 170 (e.g., by means of a CAS operation).
- multiple threads may cooperate in processing a modification and a thread in one operating system process may complete a modification begun by a thread in a different operating system process that died before the modification was completed.
- the thread may process the newly installed write task.
- a thread of the data management engine 140 may process a write task directed to an MSV object 166 as follows.
- the "current write” refers equivalently to the write task object 170 being invoked, the performance of the steps below, which may take place concurrently in multiple threads, and the intended modification.
- the write task may, in general, contain the following five steps:
- the write task obtains the current MSV state 162 associated with the MSV object 166. It is noted that this MSV state 162 may be different from the one obtained as a result of calling a process called "close_published_values()," which is described further below. Due to the serialization of tasks, no further changes may be made by other tasks until the current write task finishes.
- isolation contexts 1 10 that are associated with value chains 156 in the MSV state 162 are enumerated. For each isolation context 1 10 for which it is determined that it is possible for the current write to introduce a conflict or contingent conflict for the isolation context 1 10, the thread installs the current write task object 170 in the corresponding isolation context object 151 as a pre- publication task. This ensures that the isolation context 1 10 cannot be published until this write task 170 completes. Therefore publishing of the isolation context 1 10 does not occur until any conflicts 152 have been added to the isolation context object 151 . In this manner, if another thread (not involved with the current write task) attempts to publish one of these isolation contexts 1 10, this other thread first assists (via processing the write task 170) in deciding whether to add conflicts 152.
- a contingent conflict refers to an indication that should one isolation context 1 10 successfully publish its changes, doing so will, as part of the atomic publishing process, induce a conflict in another isolation context 1 10.
- the thread processing the write task determines the value to be associated as the result of the modification, and the write task may create a value object 158 and add the created value object 158 to the correct value chain 156.
- the thread processing the write task next identifies any conflicts 152 or contingent conflicts for each value chain 156 in the MSV state 162 and adds these conflicts 152 and contingent conflicts to the associated isolation contexts 1 10.
- the data management engine 140 may determine whether the current write implies a conflict for the value chain's associated isolation context 1 10. For example, when the value chain 156 is open, the associated isolation context 1 10 is a publishable isolation context, and the associated view 120 is a descendent of the view being modified, the thread may determine that a conflict should be added to the isolation context object 151 associated with the value chain 156.
- the thread processing the write task may determine that a conflict should be added to the isolation context object 151 associated with view 120 being modified.
- the thread processing the write task may determine that a conflict should be added to the isolation context object 151 associated with view 120 being modified.
- the thread processing the write task may remove the current write task as a pre-publication task from the isolation context objects 151 that it was added to, thereby allowing any publication(s) to proceed.
- this step may be performed as part of the prior step following the determination of any conflicts on all of the isolation context's 1 10 associated value chains 156 or following the addition of a conflict to the isolation context.
- the thread may attempt to remove the write task 170 as the pending write task 170 for the object, e.g., by using a CAS operation to replace the current write task 170 with a null value.
- the thread may make a single attempt, as failure of the CAS operation may indicate that another thread was previously successful in this removal.
- a thread may perform a check to determine whether there is already a value object 158 established on an open value chain 156 associated with the operation's view 120 since the last time the associated isolation context 1 10 was published (or at all if the isolation context 1 10 has yet to publish). If such a value object 158 exists, the value associated with the value object 158 may be returned. Otherwise, the thread may initiate a modify operation, where the value to be asserted by the modify operation may be the current value associated with the view, and this value may be returned by the frozen read operation.
- the modify operation may indicate in the value chain 156 that the value added is as the result of a frozen read and therefore, is not propagated to a value chain 156 associated with the view's 120 parent view 120 following successful publishing of the isolation context 1 10.
- the publication process may be serialized with respect to other publication tasks or other write tasks installed as pre- publication tasks (as described above) by concurrently executing threads of the system 100: a thread may install a publication task in the isolation context object 151 associated with the isolation context 1 10 to be published after cooperating in finishing any currently installed publication task or write tasks.
- a conflict or contingent conflict may not be added to an isolation context object 151 by a write task 170 unless that write task 170 has been installed as a pre-publication task 170 on the isolation context object 151 ; and a write task 170 may not be installed as a pre-publication task 170 on an isolation context object 151 that has an installed publication task 170 before the publication task is finished with the cooperation of the thread attempting to install the write task 170.
- no further conflicts may be added until after the publication attempt associated with the publication task finishes.
- the data management engine 140 installs any conflicts 152 for an associated isolation context 1 10 in the corresponding isolation context state 157. In this manner, if a given isolation context state 157 has actual conflicts 152 (i.e., non- contingent conflicts), then any attempted publication of the associated isolation context 1 10 fails, and the conflicts 152 are noted and may be addressed, as further described herein.
- actual conflicts 152 i.e., non- contingent conflicts
- isolation context 1 10 attempts to publish and has no actual conflicts 152 installed, the isolation context 1 10 is allowed to publish; any contingent conflict(s) 152 are identified and added as actual conflict(s) 152 to the isolation context object(s) 151 associated with the contingent conflict(s) 152; and the isolation context object 151 being published is updated to be associated with a new isolation context state 157 having no (actual or contingent conflicts), an updated last publication time, and its prior isolation context state 157 as a prior state.
- the determination that there are no actual conflicts 152 and the updating of the isolation context state 157 may be constrained to constitute a single logically atomic operation.
- the isolation context object 151 may include one or multiple of the following features.
- the isolation context object 151 may include an immutable reference to a parent isolation context object 151 .
- the isolation context object 151 may include an atomically-updated reference to a current isolation context state 157. This reference may be atomically changed to refer to a new isolation context state 157 whenever the associated isolation context 1 10 publishes or when a conflict or contingent conflict is created for the context 1 10.
- the isolation context state 157 may contain one or multiple conflicts 152.
- the isolation context state 157 may include a list of conflicts representing actual conflicts; a list of conflicts representing contingent conflicts; a timestamp representing the last publication time; and a reference to the prior state of the associated isolation context 1 10 as of the last successful publication of the isolation context 1 10 (if any).
- an isolation context object 151 is created, an associated isolation context state 157 may be created.
- the timestamp associated with a created isolation context state 157 may be the result of atomically implementing the event counter 164.
- the lists of conflicts and contingent conflicts may be linked lists such that creating a new isolation context state 157 based on an existing isolation context state 157 differing only in the addition of or removal of conflicts 152 on one of the conflict lists may involve isolation context states 157 whose lists share a state in a common suffix.
- the timestamps of the isolation context states 157 associated with an isolation context object 151 represent the creation time of the isolation context object 151 and its successful publications. These timestamps may be called “stable times" for the isolation context object 151 and its associated isolation context 1 10. The latest of these stable times (e.g., the timestamp of the isolation context state 157 directly associated with the isolation context object 151 ) may be called the "last stable time" for the isolation context object 151 .
- the isolation context object 151 may have an atomically-updated reference to a pre-publication task that may be a write task or a publication task that is to be completed before publication of the associated isolation context 1 10 may be attempted.
- the pre-publication task may be a single publication task or a collection of write tasks, all of which are to be completed before publication of the associated isolation context 1 10 may be attempted.
- the completion of the write tasks from the collection of write tasks may include basing whether to perform the write task on an indication of whether the task has been completed (e.g., by another thread).
- the isolation context object 151 may have an associated map, also called a "shadow map," which maps view objects 153 to other view objects 153.
- the shadow map may be a lock-free map.
- the shadow map may be a lock-free cuckoo map.
- the isolation context object 151 may have an associated immutable enumerated value that represents whether the associated isolation context 1 10 is a live or snapshot isolation context 1 10.
- the isolation context object 151 may have an immutable, enumerated value that represents the associated isolation context's modification type, which may be a publishable isolation context 1 10, a detached isolation context 1 10 or a read-only isolation context 1 10.
- a publishable isolation context 1 10 refers to an isolation context 1 10 that may be published.
- a detached isolation context 1 10 refers to an isolation context 1 10 that is constrained to be one that is not published, but values in the detached isolation context 1 10 may be modified.
- a read-only isolation context 1 10 refers to an isolation context 1 10 that is constrained to not be published, and values in the read-only context 1 10 are constrained to not be modified.
- the data management engine 140 may be constrained to not create a publishable isolation context 1 10 whose parent is a read-only isolation context 1 10, as publishing modifications from the child isolation context 1 10 would constitute an impermissible modification to the read-only parent isolation context 1 10.
- the data structures 150 include a global isolation context object 156 representing the global isolation context 1 10 and having no parent isolation context object 156.
- the isolation context object 151 may also be associated with one or multiple of the following operations.
- the isolation context object 151 may provide a shadow(view object) operation to identify a view object 153 associated with the isolation context object 151 and related to the specified view object 153. If the shadow(view object) operation determines that the isolation context object 151 is associated with the view object 153, the view object 153 is returned as the value of the shadowQ operation.
- the shadow(view object) operation involves checking the shadow map associated with the isolation context object 151 . If there is no entry in the shadow map corresponding to the view object 153, the shadow(view object) operation may include invoking the shadow(view object) operation on the parent isolation context object 151 . If the shadow map contains a view object 153 corresponding to the resulting view object 153, the corresponding view object may be returned. Otherwise, the shadow(view object) operation may create a new view object 153, as a child of the parent's shadow view object 153. The shadow(view object) operation may associate the new view object 153 with the specified view object 153 and with the parent's shadow view object 153. In this way, a hierarchy of shadow view objects 153 may be created and efficiently retrieved.
- the isolation context object 151 may provide a new_child(view type, modification type, timestamp) operation to create a child isolation context object 151 of the isolation context object 151 , where the timestamp associated with the child's isolation context state 157 is the specified timestamp or, if the timestamp is omitted or "most recent" is specified, the result of incrementing the event counter 164, and where the child has the specified view type (e.g., either "live” or "snapshot") and the specified modification type (e.g., "publishable”, "detached", or "read-only”).
- the specified view type e.g., either "live” or "snapshot
- the specified modification type e.g., "publishable", "detached", or "read-only”
- the isolation context object 151 may provide a publishQ operation to install and run a publish task, as described below, after first collaborating in finishing any publish or write tasks already installed in the context's pre-publication task.
- the isolation context object 151 may provide an add_conflict(conflict) operation to first check whether the conflict 152 has been marked as being "resolved". If not, the operation atomically replaces the current isolation context state 157 with a new isolation context state 157 identical to the current save that the conflict 152 is prepended to the conflict list. The replacement may be performed atomically by a CAS operation, looping until an attempt succeeds and creating a new isolation context state 157 each time. The operation then attempts to install the conflict 152 in a location (e.g., a value chain 156) associated with the conflict 152 to assert that there is known to be a conflict 152 at that location.
- a location e.g., a value chain 156
- the attempt to install may be made by a single invocation of a CAS operation attempting to replace a null value with the present conflict 152. Failure in this attempt implies that another conflict 152 has been installed there (e.g., by another thread), and accordingly, the present conflict 152 is marked as being resolved.
- the isolation context object 151 may provide an
- add_contingent_conflict(conflict) operation which atomically replaces the current isolation context state 157 with a new isolation context state 157 identical to the current save that the conflict 152 is prepended to the contingent conflict list.
- the replacement may be performed atomically by a CAS operation, looping until an attempt succeeds and creating a new isolation context state 157 each time.
- the isolation context object 151 may provide a
- conflict_resolved(conflict) operation to remove a conflict 152 from preventing publication of the isolation context 1 10 associated with the isolation context object 152. If the specified conflict 152 is the head of the current isolation context state's 157 conflict list, the operation replaces the associated isolation context state 157 with a new isolation context state 157 equivalent to the old one, save that all initial conflicts 152 in the conflict list that are marked as resolved are removed. In this way, in accordance with example implementations, resolved conflicts 152 may remain on the conflict list, but after all conflicts 152 have been marked as being resolved, the conflict list in the isolation context state 157 is empty.
- the isolation context object 151 may provide a
- the isolation context object 151 may provide a
- publication_after(timestamp) operation traverses the list of the isolation context states 157, starting from the current isolation context state 157 and continuing by following the prior state pointer; and returns the earliest timestamp associated with a state 157, such that the timestamp of the state 157 is after the specified one. This operation may also indicate whether there is no such timestamp.
- the isolation context object 151 may provide a
- publication_before(timestamp) operation traverses the list of the isolation context states 157, which may be similar to the publication_after(timestamp) operation. However, the publication_before(timestamp) operation returns the latest publication timestamp before the given one, or a zero timestamp (or a similar timestamp that is considered to be before any other timestamp), if the given timestamp is before the associated isolation context's creation time.
- the contingent conflict list of the isolation context state 157 may have nodes, where each node indicates a contingent conflict and has an associated "handled" flag.
- the contingent conflict associated with a node may only be added as a conflict to its associated isolation context object 151 following a determination that the flag is not set; and the flag may be atomically set following the successful addition of the conflict 152.
- the view object 153 may have one or multiple of the following properties.
- the view object 153 may contain an unchangeable, or immutable, reference to the isolation context 1 10 (as represented by object 151 ) that created it; and the view object 153 may contain an immutable reference to its parent view object 153 (which may or may not be associated with the same isolation context 1 10).
- the view object 153 may have an ancestor cache, which may be a map from view objects 153 to Boolean values, where an association in the map indicates a determination that a given other view object 153 has been determined to be or to not be an ancestor of the current view object 153.
- a true Boolean value, a false Boolean value and no entry represent whether the ancestry has been determined to be an ancestor, has been determined to not be an ancestor or is to be determined, respectively.
- the ancestor cache is not constructed until a determination is required and is atomically installed.
- the ancestor cache is a lock free map (e.g., a lock free cuckoo map).
- the data structures 150 include a top-level view object 153, which is associated with the global isolation context object 151 and which has no parent view object 153.
- the view object 153 may provide an operation that is directed to retrieving a reference to the associated isolation context object 151 .
- the view object 153 may provide a has_ancestor(view object) operation to determine whether a given view object 153 is an ancestor of the view object 153.
- the operation includes first determining whether the specified view object 153 is the same as the view object 153, the same as the parent of the view object 153, or the top-level view object 153. In any of these cases, the operation may return a true Boolean value. Otherwise, if the view object 153 is the top-level view object 153, then the operation may return a false Boolean value.
- the operation creates one and atomically associates it with the view object 153.
- the ancestor cache may be examined to determine whether the answer is known. If a Boolean value is found to be associated in the ancestor cache with the specified view object 153, the Boolean value may be returned. Otherwise, the ancestry of the view object 153 may be walked, or traversed, starting with its parent view object 153 and continuing through successive parent view objects 153 until the specified view object 153 or the top-level view object 153 is encountered. The value of the operation depends on the view object 153 encountered during the traversal of the ancestry: a Boolean true value if the specified view object 153 is encountered and a Boolean false value if the top-level view object 153 is encountered. The value of the operation may be associated with the specified view object 153 in the ancestor cache and returned.
- the conflict 152 may have one or multiple of the following properties.
- a conflict 152 may contain an atomically-updated flag to indicate, or represent, whether or not the conflict 152 has been resolved.
- a conflict 152 may contain an immutable reference to an atomically- updated reference to a conflict 152, which is the location in which this conflict is installed.
- the conflict 152 may have one or multiple subclasses holding information identifying different types of locations at which conflicts may occur.
- such subclasses may include: 1 .) a field conflict, which holds a reference to a record object and an indication of a field within that record object; 2.) a bound name conflict, which holds a reference to a
- the MSV object 166 may have one or multiple of the following properties.
- An MSV object 166 may contain an atomically-updated reference to its current state 162.
- An MSV object 166 may contain an atomically-updated reference to a pending write task, which is a write task is in progress and must be completed before another modification can be performed.
- An MSV object 166 may contain an immutable reference to a conflict generator 160.
- the type of the conflict generator 160 referred to may depend on the type of location the MSV object 166 represents (e.g., field of record or slot of array).
- Conflict generators 160 associated with different types of location may generate different instances of different subtypes of conflict 152.
- the MSV object 166 may be an instance of a template (or parameterized or generic) class, where the template parameter may indicate the type of data contained (e.g., the values contained in value objects 158 and provided to and returned by operations).
- This template parameter may also be used by the MSV state 162, value objects 158, and value chains 156, which may be nested within the class implementing the MSV object 166.
- Such an arrangement may allow different representations of value objects 158 holding different types of values, which may permit more efficient representation when values are of a primitive type (e.g., numbers, Boolean values, or characters).
- the MSV object 166 may provide one or multiple of the following operations.
- the MSV object 166 may provide a read(view, timestamp) operation to determine and return the value of the MSV object 166 for a specified view object 153 as of (i.e., no later than) the given timestamp, which, if omitted defaults to the "most recent" timestamp, indicating that the most recent value should be returned.
- a process of reading from an MSV object 166 includes invoking the current_value operation on the MSV state 162 associated with the MSV object 166.
- the MSV object 166 may provide a read_frozen(view) operation to determine and return the current (e.g., most recent) value of the MSV object 166 for the given view object 153.
- the read_frozen(view operation) ensures that
- the MSV object 166 may provide a has_value(view, timestamp) operation to indicate (e.g., via returning a Boolean value) if a read operation with the same parameters would return a value discovered in a value object 158.
- the MSV object 166 may provide a modify(view, op, resolve?, argument) operation to modify the value in the given view object 153, according to the given operation applied to the current value object 158 and (when applicable) the given argument.
- the "?” suffix denotes a Boolean value.
- the operations may include one or multiple of the following: an operation to set the value to the argument; an operation to add, subtract, multiply, or divide the current value by the argument; an operation to clear the value (e.g., set the value to a default value); and an operation set the value to a value present in the MSV object 166, where the present value may be one of the current value in the given view 120; the value in the parent view 120 of the given view object 153, the last stable value (e.g., the value as of the last stable time for the associated isolation context 1 10); and the current value, with an indication that this should be noted as implementing a frozen read.
- the "resolve?" argument controls whether this modification should be considered to resolve any conflict 152 for this view object 153 in this MSV object 166.
- the MSV object 166 may provide a write(view, resolving, new value) operation, which is an alias for the above-described operation with the operation that of setting the value to the given argument.
- operations that are provided by the MSV object 166 may be preceded by closing the published view objects 153 in a close_published_views() process, which is described below.
- the value chain 156 may have one or multiple of the following properties.
- the value chain 156 may represent the history of value objects 158, which are associated with a view object 153.
- the value chain 156 may contain immutable references to the value chain's view object 153.
- the value chain's view object 153 may contain immutable references to the value chain's view object 153.
- references may be a pointer that contains flags that record whether the view object's isolation context 1 10 is mutable and/or a snapshot.
- the value chain 156 may contain a pointer to the latest, or most recent, value object 158, and in accordance with example implementations, the pointer may contain a flag that indicates or represents whether the most recent value object 158 was due to a frozen read or equivalent operation (e.g., an operation that asserts a value equivalent to the current value, such as an operation of adding or subtracting zero or an operation of multiplying or dividing by one).
- a frozen read or equivalent operation e.g., an operation that asserts a value equivalent to the current value, such as an operation of adding or subtracting zero or an operation of multiplying or dividing by one.
- view-relative pointers may be installed on the value chain 156.
- the view-relative pointers may be associated as values in the value objects 158 that are installed on the value chain 156.
- the view-relative pointers may be constrained to be relative to some view object 153 that shares an isolation context 1 10 with the view object 153 of the value chain 156.
- the value chain 156 may contain an atomically-updated reference to a conflict 152 that is associated with the value chain 156. This may be a null reference to indicate a lack of a conflict.
- the value chain 156 may provide one or multiple of the following operations.
- the value chain 156 may provide a value(timestamp) operation to return a reference to the value object 158 representing the latest value object 158 in the value chain 156 before the given timestamp, or provide a null reference, if no such value object 158 exists.
- the operation may involve traversing the value chain 156 by starting at the latest value object 158 associated with the 158 and following each value object's link to the prior value objects 158.
- the value chain 156 may provide an add_value(value) operation to update the most recent value object 158 reference to a new value object 158 with the provided value.
- the timestamp of the new value object 158 may be the current value of the event counter 164, and the prior pointer of the new value object 156 may refer to the old most recent value object 158.
- the add_value(value) operation may return the newly added value object 158.
- the prior pointer for the new value object 158 may be set to the prior pointer of the old most recent value object 158, rather than the prior pointer of the most recent value object 158, for the case in which the timestamp of the old most recent value object 158 is the current value of the event counter 164. This allows the old most recent value object 158 to be garbage collected (assuming there are no other references to it).
- the new value object 158 replaces the old most recent value object 158, rather than extending the chain of value objects 158. It is noted that this is permissible because if the event counter 164 has not been incremented, this means that no snapshot has been created since the last time a value was added to the value chain 156. Therefore, with no snapshot being created after the last time a value was added to the value chain 156, a future read of the MSV object 166 would not have otherwise correctly returned the old most recent value object 158.
- the most recent value object pointer contains a read-in-snapshot flag, indicating whether the value from the most recent value object 158 in the value chain 156 was read after following the parent link of a view object 153 associated with a snapshot isolation context 1 10 (e.g., when the timestamp of the read is a stable time for a snapshot rather than the "most recent" timestamp).
- a value e.g., in the value(timestamp) operation
- the timestamp is other than the "most recent" timestamp and the read-in-snapshot flag is not already true, before walking the chain of value objects 158, the reference to the most recent value object 158 (including its read-in-snapshot flag) is remembered.
- the value object 158 found is the most recent value object 158, a single attempt is made to replace the remembered value object reference with an identical one that has the read-in- snapshot flag set to true. If this attempt fails, it means that either some other thread succeeded (i.e., a failure occurred due to the assumption that the false value for the read-in-snapshot flag was wrong) or another value object 158 was added to the value chain 156 (i.e., a failure occurred because the most recent value object 158 reference had changed). Either cause of failure removes the problem. When adding a value object 158, the old most recent value object reference may be read before the current timestamp is read.
- the current timestamp is incremented upon the creation of a snapshot, it may be inferred that either the read-in-snapshot flag of the read most recent value object reference is false or the current timestamp was incremented since the last value object 158 (e.g., the current most recent value object 158) was added to the value chain 156.
- the new value for the most recent value object reference has the read-in-snapshot flag set to false. If it is the case that the read-in- snapshot flag was set in between the time the read of the most recent value object reference was made and the time of the attempted update, then the CAS operation to change the most recent value object reference from the read value to the new value fails.
- the MSV state 162 indicates states for value chains 156 of an associated MSV.
- the MSV state 162 contains an array of value chains 156 (by reference).
- Each value chain 156 may be considered “publishable” or “unpublishable” based on its associated isolation context.
- Each value chain 156 may further be considered to be "open” or "closed”.
- An open value chain 156 is one on which a value object 158 was added subsequent to the last stable time of the associated isolation context 1 10 as of the time the MSV state 162 was created.
- a closed value chain 156 is one that is not an open value chain 156.
- a closed value chain 156 is publishable, and an unpublishable value chain 156 is open.
- the value chains 156 may be arranged in the array such that all open value chains 156 preceded all closed value chains 156 and all unpublishable value chains 156 precede all publishable value chains.
- the first entry in the array may be reserved for a value chain 156 that is associated with the top-level view object 153.
- This value chain 156 is unpublishable (since the top-level view object 153, which lacks a parent is unpublishable) and as such, may be considered open even if it has no value objects 158.
- the MSV state 162 may contain an indication of the number of contained unpublishable value chains 156, the number of open publishable value chains 156, and the number of closed value chains 156. These numbers allow the determination of the state of a value chain 156 based on its position within the array.
- the MSV state 162 may provide one or multiple of the following operations.
- the MSV state 162 may provide the close_published_views() operation, which is further described below.
- the MSV state 162 may provide a values(view, open only?) operation to return the value chain 156 that is associated with the specified view object 153, if it exists. If the "open only?" parameter is a Boolean true value, then a value chain 156 is not returned unless the value chain 156 is found among the open (e.g., unpublishable and open publishable) value chains 156.
- the MSV state 162 may provide a current_value(view, timestamp) operation to return the value associated with the view object 153 as of the specified timestamp.
- this operation may traverse parent view objects 153 and the timestamp may be modified when traversing parent view objects 153 of view objects 153 associated with snapshot isolation contexts 1 10.
- the operation may begin at the specified view object 153 and may call the values(view, open only?) operation to get the value chain 156 associated with the view object 153.
- the "open only?” parameter to the operation may be the Boolean true value just in case the specified timestamp is the "most recent" timestamp.
- the current_value operation may call value(timestamp) on this result to get a value object 158. If none is found, the operation may replace the current view object 153 by its parent view object 153. If the current view object 153 is associated with a snapshot isolation context 1 10, the operation may replace the timestamp with the last stable time of the isolation context 1 10 prior to the timestamp by calling the
- the search may be performed again, and this process may continue until a value object 158 is found or the parentage is exhausted.
- a value object 158 is found, it is returned, otherwise a null pointer is returned.
- a value chain 156 associated with a parent view object 153 that is associated with an isolation context 1 10 that is not read only
- the timestamp is the "most recent timestamp”
- the MSV state 162 has been replaced in the MSV object 166 with a new one that has a value chain 156 for that view object 153; and the modification that added the value chain 158 took place before the value object 158 found was added.
- value chain 156 contains the value object 158 that should have been returned by the operation.
- the current_value(view, timestamp) operation returns (as a secondary return value) an indication that the value 153 returned should not be trusted if the MSV's state has changed.
- the caller attempts to confirm that the MSV state 162 is still associated with the MSV object 166. If this is not the case, the caller may call current_value() on the new state. This process may repeat until the secondary return indication is not seen or the MSV object's 166 current state has not changed.
- an MSV object 166 may provide a
- close_published_views() operation to update the MSV object 166 to be associated with an MSV state 162 that reflects all publications of isolation contexts 1 10 that have happened since the last time close_published_views() was called.
- the close_published_views() operation may accept as a parameter a view object 153 (called the "write view” below) indicative of a view 120, if any, that the caller intends to assert a value in and which, therefore is associated with an open value chain 156 in the resulting MSV state 162.
- the operation may return the following values: 1 . the resulting MSV state 162, which if not null, has been installed in the MSV object 166; 2. the value chain 156 associated with the write view (if specified) in the resulting MSV state 162; and 3. an indication of whether the returned value chain 156 (if any) was an open value chain 156 prior to the operation.
- a thread executing in the data management engine 140 may perform the following actions when executing the closed_publ ished_views() operation :
- the thread reads the current state of the MSV state 162 (called the
- the thread If there was no remembered state (e.g., if the current state of the MSV object 166 was a null reference), then if there is no write view object 153, the thread returns a null MSV state 162 reference. Otherwise, the thread creates a new value chain 156 associated with the write view. If the write view is not the top- level view object 153, the thread may also create a value chain 156 associated with the top-level view object 153. The thread then creates a new MSV state associated with an array containing the created value chains 156 and recording the number of unpublishable and open publishable value chains 156 this represents. The thread returns the created MSV state 162, the value chain 156 associated with the write view, and an indication that the returned value chain 156 was not open.
- the thread calls a find_need_close() operation on the MSV state 162, which returns a priority queue indicating open publishable value chains 156 whose associated with isolation context objects 151 that have been published more recently than the timestamp of the most recent value object 158 on the value chain 156.
- the priority queue may be ordered from least-recently published to most-recently published, and the elements may include the publication time following the most recent value object's 158 timestamp and an index in the value chain 156 array of the MSV state 162. It is noted that the timestamp stored in the priority queue may not be reflect the most recent publication of the isolation context object 151 . In searching for value chains 156 to add to the priority queue, if the thread discovers a value chain 156 associated with the write view 153, it may remember it for later use.
- the thread may return from the operation: the current MSV state 162, the write value chain 156 (if any), and, if a write value chain 156 was found, an indication that the write value chain 156 was previously open.
- a write view object 153 was specified and no associated value chain 156 was discovered, it may be inferred that no write value chain exists among the open publishable value chains 156. If the write view object 153 is associated with an unpublishable isolation context 1 10, a search may be made through the unpublishable value chains 156 associated with the MSV state 162. As an optimization, if the write view object 153 is the top-level view object 153, an associated value chain 156 may be found as the first value chain 156 among the unpublishable value chains 156. If an associated value chain 156 is found, it may be returned, along with the current MSV state and an indication that the value chain 156 was previously open.
- a new MSV state 162 may be made that is a copy of the remembered state with the addition of a new unpublishable value chain 156 associated with the write view 153. If the thread succeeds in installing new MSV state 162 replacing the remembered state, the new MSV state 162, the new value chain 156, and an indication that the value chain 156 was not open may be returned. Otherwise, the close_published_views() operation is retried from the beginning and the values returned.
- a search may be made through the closed value chains 156 associated with the MSV state 162. If an associated value chain 156 is found, a new MSV state 162 may be made that is a copy of the remembered state, save that the found value chain 156 is moved to become an open publishable value chain 156. If the thread succeeds in installing new MSV state 162 replacing the remembered state, the new MSV state 162, the found value chain 156, and an indication that the value chain 156 was not open may be returned. Otherwise, the close_published_views() operation is retried from the beginning and the values returned.
- a new MSV state 162 may be made that is a copy of the remembered state with the addition of a new open publishable value chain 156 associated with the write view 153. If the thread succeeds in installing new MSV state 162 replacing the remembered state, the new MSV state 162, the new value chain 156, and an indication that the value chain 156 was not open may be returned. Otherwise, the close_published_views() operation is retried from the beginning and the values returned.
- process_close() may be called on the current MSV state 162, passing in the priority queue and the write view object 153. The operation returns the same three values, which are remembered.
- the process_close() operation has access to the priority queue and the write view object 153 (if any) of its caller, and in accordance with example implementations, maintains the following structures: a vector of open publishable value chains 156; a vector of closed value chains 156; and a vector of new unpublishable value chains 156. It is noted that the designation of these value chains 156 as, e.g., open publishable, represent the point of view of an MSV state 162 being designed and the designation for a given value chain 156 may change during the operation.
- the vector of open publishable value chains 156 may initially contain the open publishable value chains 156 in the MSV state 162. Whenever a new open publishable value chain 156 is created or a closed value chain 156 is reopened, the value chain 156 is added to the end of this vector. Whenever a value chain 156 is closed, the slot in the vector is replaced by a null pointer. A side count may be maintained, representing the number of non-null entries in the vector.
- the vector of closed value chains 156 may initially contain the closed value chains 156 in the MSV state 162. In accordance with an implementation, the creation of this vector may be deferred until there is a need to alter its contents. Whenever an open publishable value chain 156 is closed, the value chain 156 is added to the end of the vector. Whenever a closed value chain 156 is reopened, its slot in the vector is replaced by a null pointer. A side count may be maintained, representing the number of non-null entries in the vector.
- the vector of new unpublishable value chains 156 may initially be empty. When a new unpublishable value chain 156 is created, the value chain 156 is added to the end of the vector.
- the unpublishable value chains 156 of the MSV state 162 being designed comprise the unpublishable value chains 156 of the current MSV state 162 and the contents of this vector.
- the process_close() operation may repeatedly remove items from the priority queue and identify value chains 156 and publication timestamps, where the values removed reflect the earliest such timestamps in the priority queue, stopping when the priority queue is empty.
- Each such value chain 156 (which may be called a child value chain) is in the open publishable value chain 156 vector.
- the operation next identifies the parent value chain 156 associated with the parent view object 153 of the view object 153 associated with the child value chain 156. If the parent value chain 156 is identified in the open publishable value chain 156 vector, the unpublishable value chain 156 vector, or the unpublishable value chains 156 of the current MSV state 162, it is noted.
- a new parent value chain 156 is created and add it to the unpublishable value chain 156 vector. If the parent view object 153 is associated with a publishable isolation context 1 10, a search is made through the closed value chain 156 vector (or, if this has not yet been created, the closed value chains 156 associated with the current MSV state 162). If a parent value chain 156 is found, the parent value chain 156 is reopened by removing it from the closed value chain 156 vector and adding it to the open publishable value chain 156 vector. If a parent value chain 156 is not found, a new parent value chain 156 is created and added to the open publishable value chain 156 vector.
- the child value chain 156 may then be closed, and modifications (if any) of the child value chain 156 are transferred to its parent.
- the child value chain 156 may be removed from the open publishable value chain 156 vector. If there is an indication in the child value chain 156 that the most recent value object 158 was added as the result of a frozen read operation, there is no value that needs to be transferred to the parent value chain.
- the most recent value object 158 associated with the child value chain 158 may be removed from the child value chain 156 along with the indication. If this results in a child value chain 156 with no associated most recent value object 158, the child value chain 156 may be discarded.
- the most recent parent value object 158 (if any) is discovered on the parent value chain 158. If the most recent parent value object 158 exists and the associated timestamp is greater than or equal to one less than the timestamp retrieved from the priority queue, this may indicate that another thread has already processed the publication of the child view object 153, so this thread need not.
- a new parent value object 158 is created based on the most recent child value object 158, having a timestamp equal to the retrieved timestamp minus one and the same value unless the value is a view-relative pointer 154, in which case the value is a copy where the view object 153 associated with the copy is the parent of the view object 153 associated with the original.
- the prior value object 158 of the new parent value object 158 is the old most recent parent value object 158, if any.
- the operation then makes a single attempt to atomically replace the old most recent parent value object 158 with the new parent value object 158 in the parent value chain 156. A failure in this attempt may indicated that another thread has already processed the publication of the child view object 153.
- the parent view object 153 is associated with a publishable isolation context 1 10, a determination is made as to whether the parent isolation context 1 10 was published following the retrieved timestamp. If it was, a new entry is added to the priority queue reflecting the parent value chain 156 and the earliest publication time of the parent isolation context 1 10 following the retrieved timestamp. It is noted that this step is performed even if an earlier determination was made that another thread installed a new parent value object 158 reflecting the current child value object 158.
- the thread may proceed to identify the write value chain 156 associated with the write view object 153, if any. This may be performed by the same procedure as was used to identify each parent value chain 156.
- the thread may create a new MSV state 162 associated with the unpublishable value chains 156 from the current MSV state 162, the unpublishable value chains 156 from the unpublishable value chain 156 vector, the open
- publishable value chains 156 from the open publishable value chain 156 vector, and the closed value chains 156 from the close value chain 156 vector (or if this last has not been created, from the current MSV state 162).
- the thread may then return this new MSV state 162, the write value chain 156 (if any) and an indication of whether the write value chain 156 was found among the open value chains 156.
- Cooperative tasks are described herein for purpose serializing operations, such as publication and adding conflicts to an isolation context or modifying a value.
- Each point of serialization may be associated with a "task holder.”
- the task holder refers to a task and may be atomically updated.
- the task is first installed in the holder. This installation may involve attempting to replace a null pointer in the task holder with a reference to the task by means of the CAS operation. If the task holder was not empty, then this attempt fails, and the current value is obtained. If the blocking task is not the one being installed (i.e., if it was not the case that another thread was successful in installing it), then the task is run in the current thread, and an attempt is made to replace the task with null. If this fails, it means that another thread removed it first, so another iteration occurs to try the install again. When the task is successfully installed, the task is then run and then an attempt is made to remove it (replace it with null). [00160] In accordance with example implementations, the work of the task may occur in the task's run() operation, which may be defined in a subclass.
- Publish tasks may be installed in the isolation context objects 151 to (attempt to) perform a publication of the corresponding isolation context 1 10.
- the publish tasks are in competition for this task holder with other publish tasks and with write tasks that may wish to add conflicts to this context.
- the publish task may have one or multiple of the following properties.
- the publish task may have an immutable reference to the isolation context object 151 being published.
- the publish task may have an atomically-updated timestamp representing the publish time (initially zero).
- the publish task may have an atomically-updated reference to a list of conflicts seen by the publish task. This atomically-updated reference may contain a "has value" flag, initially false, to be able to distinguish between the scenario in which it is unknown whether there are any conflicts 152 and the scenario in which it has been determined that there are no conflicts 152.
- the isolation context object's 151 associated isolation context state 157 is requested to attempt to publish as of the determined publish time.
- This may request may return a list of conflicts 152, which may be an empty list, indicating successful publication. This list may be installed in the task via the conflicts reference with the has-value flag set. The publish task is complete.
- an isolation context state 157 associated with an isolation context object 151 may attempt to publish as of a specified publication timestamp as follows:
- the corresponding contingent conflict list is traversed, adding each contingent conflict 152 to its associated isolation context object 151 .
- the nodes in the list may contain a "handled?” flag, which is checked before adding and set afterwards, to minimize duplicate work as threads run through the list at the same time.
- a count of the contingent conflicts 152 handled is maintained, and a handling flag is used in addition to the "handled?" flag.
- a handling flag is used in addition to the "handled?" flag.
- contingent conflicts 152 having states that may be changed from unhandled to handling are added, the state then being changed unconditionally to handled, and a counter may then incremented.
- the count did not equal the number of items of the entire list, this means that some thread claimed an entry and then terminated or paused; and when this occurs, a second pass may be performed, adding all contingent conflicts who are in handling and incrementing the counter for each of these conflicts if its state may be changed from handling to handled.
- a new isolation context state 157 is constructed with the given publication timestamp and whose prior state is the current isolation context state 157.
- the failed attempt identifies the isolation context state 157 associated with the isolation context object 151 , and the operation may return the result of asking this isolation context state 157 to attempt to publish as of the specified timestamp.
- a publish result object is created based on the publish time and conflict list stored in the task.
- the creation of the publish result object may be performed outside of the publish task.
- the publish result object contains an immutable reference to the isolation context object 151 that was published; an immutable timestamp representing the publish attempt time; and an immutable list of blocking conflicts 152, which is empty if the publish attempt succeeded.
- a write task is installed to make a modification to an MSV object 166. It is noted that the modification may introduce a conflict in a publish task that might otherwise be occurring at the same time in a different thread.
- a write task may also be installed in an isolation context object 151 (in competition with one or multiple publish tasks) when it is determined that there is a possibility that the modification may induce a conflict.
- a write task forces a serialization of all modifications of a given field, regardless of isolation contexts.
- some modifications may be made directly on the MSV state 162 associated with the MSV object 166 without installing corresponding write tasks.
- such modifications may include those which cannot be affected by other modifications to the same MSV object 166 (e.g., operations to set a value in any view 120 and any modification operation in a view 120 associated with a snapshot isolation context 1 10) and cannot introduce conflicts 152 into isolation context objects 151 (e.g., operations in views 120 associated with non-snapshot isolation contexts 1 10 that have no child isolation contexts 1 10 and are either non-publishable or have no publishable sibling isolation contexts 1 10).
- isolation context objects 151 e.g., operations in views 120 associated with non-snapshot isolation contexts 1 10 that have no child isolation contexts 1 10 and are either non-publishable or have no publishable sibling isolation contexts 1 10).
- the performance of a write task may entail the performance of one or more phases: a cache state phase, an install context events phase, an add value to value chain phase, and an add conflicts phase.
- a write task may contain an atomically-updated indication of the current phase being performed by some thread or an indication that all phases have been completed.
- a write task may contain an immutable reference to the MSV object 166 and may contain an immutable reference to the write value chain 156 to be modified.
- a write task may contain a Boolean value (initially false), which represents whether the write value chain 156 was modified.
- a write task may contain an immutable modification operation (e.g., an operation to set or add).
- a write task may contain an immutable argument to the operation.
- a write task may contain an immutable indication of whether the modification resolves conflicts.
- a write task may contain an atomically-updatable reference (initially null) to an MSV state 162.
- a write task may contain an atomically- updatable timestamp (initially null) that represents the start time of the operation.
- a write task may contain the value returned to be returned by the modification operation.
- the thread When a thread performs the write task, the thread reads the indication of the current phase, performs the associated action and attempts to update the current phase indication by replacing the indication of the phase performed with an indication of the next phase (or that the write task is complete if there is no next phase). If this fails, it may be inferred that another thread already recorded the completion of the phase and may have performed later phases. The thread continues processing based on the resulting phase indication (e.g., the phase indication set by the thread or by another thread) until the current phase indication indicates that the write task is complete.
- the resulting phase indication e.g., the phase indication set by the thread or by another thread
- the thread performs the following in order. First, the thread attempts to change the start time from zero to a value read from the event counter 164. If this attempt fails, then the start time has been set by another thread. Next, in the cache state phase, the thread makes an attempt to change the cached state from null to the MSV state 162 currently associated with the MSV object 166. If the attempt fails, it may be inferred that another thread made the change. This sequence ensures that publication of an isolation context object 151 after the recorded start time cannot invalidate the recorded MSV state 162.
- the thread adds the write task to every isolation context object 151 for which the present modification could possibly create a conflict.
- the installed write task in a given isolation context 151 therefore causes a check for conflicts to be performed due to the installed write task before the given isolation context 151 may publish. If there are is a publish task installed on such an isolation context object (indicating an ongoing publication), the thread assists in completing the publish task (i.e., the thread assists the ongoing
- the thread adds the write task to every isolation context object 151 associated with an open publishable value chain 156 in the MSV state 166, including the write value chain 156, with the exception of those value chains 156 that are already associated with a conflict 152.
- An atomically-updatable integer indicating the next value chain 156 associated with the MSV state 162 to process may be used to ratchet the next slot to consider, allowing threads to avoid trying to add the write task to an isolation context object 151 that has already received it from another thread.
- the thread After installing the task on each isolation context object 151 , the thread checks to see whether the isolation context object 151 was published after the start time. If the thread determines that the isolation context object 151 was published after the start time, then the publish occurred after the creator of the task called the close_published_views() process. Therefore, in accordance with example
- the thread calls the closed_published_views() process again on the cached MSV object 166 and updates the cached MSV state 162 to the result.
- an indication that the thread is already processing a write task may be passed, to prevent the close_published_views() process from clearing the pending write task on the MSV object 166.
- the task may also update the cached start time to the current timestamp (unless the cached start time was already greater due to the time being set by another thread after the current time was read).
- a thread may perform the following operations:
- the value is computed based on the operation and argument and stored in the task. This computation may not be performed in an atomic manner, as an assumption may be made that repeated evaluations will yield the same value.
- isolation context 1 10 was published after the last value added was added to the write value chain 156, the otherwise unnecessary modification may be deemed to be necessary.
- the call to the add_value() operation may be specified to indicate in the write value chain 156 that the value object 158 added was the result of a frozen read.
- the thread adds the actual and contingent conflicts and removes the write task from all isolation context objects 151 , as described below:
- the thread removes the write task (if present) from the isolation context objects 151 associated with all open publishable value chain 156 in the MSV state 162, and the phase is complete.
- all open value chains 156 are enumerated. This enumeration may use an atomically updated integer associated with the write task, in the manner used when adding the write task to isolation context objects 151 in order to allow threads to not redo work done by other threads.
- the current view object 153 and current isolation context object 151 associated with the current value chain 156 in the enumeration are noted. 3. If the current value chain 156 is the write value chain 156 or if the current value chain 156 was last modified prior to the last modification to the write value chain (if any), it is determined that no conflict can be introduced with respect to the current value chain 156 by this modification.
- the write task may be removed from the current isolation context object 151 unless that is the write isolation context object 151 .
- the system 100 may be a system 800 of one or multiple physical machines 810, as depicted in Fig. 8.
- the physical machine 810 is a processor-based machine that is constructed from machine executable instructions, or "software" 860 and actual hardware 820.
- the hardware 820 of the physical machine 810 may include, for example, one or multiple processing cores 822 (e.g., central processing unit (CPU) cores and/or graphics processing unit (GPU) cores), a memory 824, one or multiple network interfaces 826, one or multiple mass storage devices 827, a display, input/output (I/O) devices and so forth.
- the memory 824 may be a non-transitory memory, which includes non-transitory memory storage devices, such as semiconductor memory devices, phase change memory devices, random access memory (RAM) devices, dynamic RAM (DRAM) devices, resistive memory devices, flash memory devices, a combination of one or more of these devices, and so forth.
- non-transitory memory storage devices such as semiconductor memory devices, phase change memory devices, random access memory (RAM) devices, dynamic RAM (DRAM) devices, resistive memory devices, flash memory devices, a combination of one or more of these devices, and so forth.
- the machine executable instructions 860 may be stored in a non-transitory computer-readable storage medium, such as the memory 824, for example.
- the instructions 860 when executed by one or multiple of the processing cores 822, may cause the processing core(s) 822 to execute one or multiple applications 866, i.e., execute the program code 1 12 as part of one or multiple operating system processes 864.
- One or multiple processes 864 may share a given isolation context, as discussed herein.
- the machine executable instructions 860 may include an operating system 865, a virtual machine monitor (VMM) 869, or hypervisor, as well as program instructions 868 that, when executed by the processing core(s) 822 cause the core(s) 822 to provide the data management engine 140.
- VMM virtual machine monitor
- hypervisor program instructions 868 that, when executed by the processing core(s) 822 cause the core(s) 822 to provide the data management engine 140.
- the physical machine 810 may store, in accordance with example implementations, data 870, such as data 872 for the data structures 160, data for the objects described herein, and so forth.
- the system 800 may include a high speed interconnect 880 (a server rack backplane, a server cabinet backplane, a bus, a serial link, and so forth) that interconnects multiple physical machines 810.
- a high speed interconnect 880 a server rack backplane, a server cabinet backplane, a bus, a serial link, and so forth
- the system 800 may include three or more physical machines.
- the system 800 may include a single physical machine 810.
- the machines 810 may be disposed at a single physical location (or facility) or may be geographically distributed at multiple locations.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
L'invention concerne une technique qui consiste à utiliser un objet à valeurs simultanées multiples auquel est associé un premier ensemble de valeurs qui est associé à une première vue qui est associée à un premier contexte de calcul d'une machine à processeur. L'objet est associé à un second ensemble de valeurs qui est associé à une seconde vue qui est associée à un second contexte de calcul de la machine à processeur. La technique comprend la tentative de publication du second contexte de calcul ; avant la tentative de publication, la détection d'un conflit de publication ; et en réponse à la tentative de publication, la commande de la publication du second contexte de calcul sur la base au moins en partie du conflit de publication détecté.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/US2015/063051 WO2017095387A1 (fr) | 2015-11-30 | 2015-11-30 | Objet à valeurs simultanées multiples |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/US2015/063051 WO2017095387A1 (fr) | 2015-11-30 | 2015-11-30 | Objet à valeurs simultanées multiples |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2017095387A1 true WO2017095387A1 (fr) | 2017-06-08 |
Family
ID=58797694
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2015/063051 WO2017095387A1 (fr) | 2015-11-30 | 2015-11-30 | Objet à valeurs simultanées multiples |
Country Status (1)
Country | Link |
---|---|
WO (1) | WO2017095387A1 (fr) |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020087500A1 (en) * | 1998-08-18 | 2002-07-04 | Brian T. Berkowitz | In-memory database system |
US20090031310A1 (en) * | 2007-07-27 | 2009-01-29 | Yosef Lev | System and Method for Executing Nested Atomic Blocks Using Split Hardware Transactions |
US20090307466A1 (en) * | 2008-06-10 | 2009-12-10 | Eric Lawrence Barsness | Resource Sharing Techniques in a Parallel Processing Computing System |
US20110289478A1 (en) * | 2006-03-30 | 2011-11-24 | Microsoft Corporation | Organization of application state and configuration settings |
US20140195766A1 (en) * | 2013-01-04 | 2014-07-10 | Microsoft Corporation | Shared and managed memory unified access |
-
2015
- 2015-11-30 WO PCT/US2015/063051 patent/WO2017095387A1/fr active Application Filing
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020087500A1 (en) * | 1998-08-18 | 2002-07-04 | Brian T. Berkowitz | In-memory database system |
US20110289478A1 (en) * | 2006-03-30 | 2011-11-24 | Microsoft Corporation | Organization of application state and configuration settings |
US20090031310A1 (en) * | 2007-07-27 | 2009-01-29 | Yosef Lev | System and Method for Executing Nested Atomic Blocks Using Split Hardware Transactions |
US20090307466A1 (en) * | 2008-06-10 | 2009-12-10 | Eric Lawrence Barsness | Resource Sharing Techniques in a Parallel Processing Computing System |
US20140195766A1 (en) * | 2013-01-04 | 2014-07-10 | Microsoft Corporation | Shared and managed memory unified access |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Tu et al. | Speedy transactions in multicore in-memory databases | |
Yang et al. | A wait-free queue as fast as fetch-and-add | |
US8473950B2 (en) | Parallel nested transactions | |
US9047334B1 (en) | Merge-update for efficient atomic memory modification in concurrent computer systems | |
Feldman et al. | A wait-free multi-word compare-and-swap operation | |
US20140108366A1 (en) | Performance Of RCU-Based Searches And Updates Of Cyclic Data Structures | |
EP4028901B1 (fr) | Stockage persistante des fichier pour mappage direct des bases de donnees | |
Merrifield et al. | Conversion: Multi-version concurrency control for main memory segments | |
US10936574B2 (en) | System and method for use of lock-less techniques with a multidimensional database | |
Wang et al. | Eunomia: Scaling concurrent search trees under contention using htm | |
US20110107338A1 (en) | Selecting isolation level for an operation based on manipulated objects | |
US8095731B2 (en) | Mutable object caching | |
Moreno et al. | On the implementation of memory reclamation methods in a lock-free hash trie design | |
Painter et al. | Lock-free transactional adjacency list | |
Huang et al. | Opportunities for optimism in contended main-memory multicore transactions | |
Felber et al. | Elastic transactions | |
Lin et al. | Operation-level concurrent transaction execution for blockchains | |
Yi et al. | A Universal Construction to implement Concurrent Data Structure for NUMA-muticore | |
Lamar et al. | Lock-free transactional vector | |
Shafiei | Non-blocking Patricia tries with replace operations | |
Sheng | Non-blocking Lazy Schema Changes in Multi-Version Database Management Systems | |
Cai et al. | Transactional Composition of Nonblocking Data Structures | |
WO2017095387A1 (fr) | Objet à valeurs simultanées multiples | |
WO2017095388A1 (fr) | Gestion de contexte d'isolation | |
Howard | Extending relativistic programming to multiple writers |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 15909904 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 15909904 Country of ref document: EP Kind code of ref document: A1 |