Peer to Patent, Community Patent Review

APPLICATION LIST|ARCHIVED APPLICATIONS|US PATENT CLASSIFICATIONS

Home > Archived Applications > 20070198518 > Discussion

Pre-Grant Publication Number: 20070198518

Synchronized objects for software transactional memory

Collaborate on the process of community review for this application. Posting will not be forwarded to the USPTO. Flagging a post as an ACTION ITEM signals further research. Flagging SPAM and ABUSE helps to manage discussion. Placing double brackets around a reference to a claim or prior art will create a hyperlink to the original ex. [[claim 1]] and [[prior art 2]].

Please review the Community Code of Conduct prior to posting

Discussion (13)

View: Date|Claims|Prior Art|Action Item|

Facilitator's Comment

Action Item

Show without Noise

PRIOR ART REFERENCE 1

The dispatch manager may also operate to determine which BIOS modules are required for operation of the computer and determine if a required BIOS module is stored in the system memory. If the required BIOS module is stored in memory, then the dispatch manager executes the stored BIOS module. However, if the required BIOS module is not in memory, then the dispatch manager copies the required BIOS module from the secondary nonvolatile storage device to the system memory and then executes the copied BIOS module. The dispatch manager repeats this procedure until all required BIOS modules are copied and executed. Once all of the required BIOS modules are copied into the system memory and executed, the operating system of the computer is launched and normal computer operation ensues.

Comments

Steven Pearson (11 months ago)

Regarding Prior Art Reference 1, at first blush I don't see this as being all that similar to sagas. Sagas are a collection of *related* subtransactions *spread out over time* within a long lasting outer transaction, whose effects are either all eventually committed or all aborted. In the case of a saga rolling back, it is not done directly (at least for already closed subtransactions, which are individually committed), but rather through the use of compensating transactions. The current application appears to me to marry a rather standard distributed commit protocol with something akin to the "uncommitted read" isolation level of the database world. Here, a group of *unrelated*, *concurrent* activities, being conceptualized as "transactions," can share access to a memory item and will all be rolled back in case something goes wrong in any one of them. The assumption seems to be that if any of the "transactions" that shares a memory item would have an incorrect outcome due to the sharing, or if any transaction was in some other way bad, all would roll back to avoid making persistent any effect or knock-on effect. But it's not clear to me that an incorrect outcome resulting from memory sharing would naturally be detectable by at least one of the sharers, so I'm not initially convinced that this approach is truly "safe". Anyway, I believe that the potentially novel piece has to do with the memory sharing aspect and not with the transactional aspect. more...

PRIOR ART REFERENCE 80

Long lived transactions (LLTs) hold on to database resources for relatively long periods of time, significantly delaying the termination of shorter and more common transactions. To alleviate these problems we propose the notion of a saga. A LLT is a saga if it can be written as a sequence of transactions that can be interleaved with other transactions. The database management system guarantees that either all the transactions in a saga are successfully completed or compensating transactions are run to amend a partial execution. Both the concept of saga and its implementation are relatively simple, but they have the potential to improve performance significantly. We analyze the various implementation issues related to sagas, including how they can be run on an existing system that does not directly support them. We also discuss techniques for database and LLT design that make it feasible to break up LLTs into sagas.

Comments

Steven Pearson (11 months ago)

Doh! Make that Prior Art Reference 80; P2P seems to use global numbering here not application-relative numbering. more...

PRIOR ART REFERENCE 88

An apparatus for dispatching client requests for execution by a server object in a heterogeneous object-oriented client/server computing environment, the apparatus comprising: a request-holding buffer having an input connected to a communications channel which channels the client requests to the apparatus, and an input; a plurality of parallel execution threads connected to the output of the buffer; and a semantic concurrency control means for examining the semantics of a request in the buffer and the semantics of each request presently being executed on any of the plurality of parallel execution threads, and for delaying the request from being dispatched from the buffer to an execution thread if the examined semantics of the requests indicate that such dispatch would cause conflicting access to the server object's resources, thereby allowing for concurrency control to take place without the use of locks.

Comments

Steven Pearson (10 months ago)

Can you please explain in more detail how Prior Art Reference 88 covers this application? I can see that one aspect of its goal is similar, i.e., lock avoidance, but the means and other goals appear to be different. This prior art teaches a scheduling mechanism that delays potentially conflicting transactions such that locks are not needed (because concurrency is prevented by this other means of delay). This does not seem to provide any higher concurrency, which is a goal and result of the application’s approach. Rather, lock avoidance in this reference is intended to avoid overheads associated with locking techniques. On the other hand, the application specifically allows concurrency, only preventing new accesses once existing accessors are already in the process of committing (and this seems a different criterion than the reference’s semantic concurrency control means). The application further provides for a co-commitment mechanism among the concurrent accessors, nothing like which is discussed in this reference. more...

0 days left