This section reviews systems related to Rhino. We include in our review object-oriented databases and persistent languages, since they are closely related to transactional memory.
ObjectStore [odi], QuickStore [white], and QuickSilver [schmuck] are client-server systems in which a server process manages transactions, and clients perform IPC to the server to access database contents. The advantage of this approach is that servers can transparently support clients running on different hosts. However, this approach also means that even local clients must communicate through a slow IPC channel, thus creating performance problems.
RVM [rvm] and Texas [texas] are implemented as a library that is linked into user-space applications. Since they have no IPC overhead, unlike client-server systems, they can be fast. However, they are inherently single-user database systems, because there is no single authority that allows safe data sharing.
A problem common to the systems discussed thus far is double paging, since they are implemented as ordinary user-space applications. The only way to solve the double paging problem is to reserve a fixed amount of memory for the database management system and let the system perform its own paging. This approach is effective when the whole machine is dedicated to the database service. However, when there are other applications competing for memory, which is typical in transactional memories, this solution does not work well.
Some systems try to solve the double paging problem by using memory-mapped files and a special system call that lets user programs control the way pages are evicted. RPVM [rpvm] adds a system call that dictates the order of page eviction. By telling the kernel to purge a buffer page after it purges log pages that record updates to that page, write ahead logging (WAL) can be implemented. Camelot [camelot] and Cricket [cricket] use the Mach external pager mechanism [machDuality] to implement WAL. One difference between these systems and Rhino is that the former are user-space applications. Thus, they cannot avoid overhead due to a large number of user-kernel crossings.
Vista[vista] uses Rio, a non-volatile file buffer, to implement transactions. Rio makes all updates to the buffer permanent immediately by recovering buffer contents during the system reboot. Thus, Vista transactions are orders of magnitude faster than transactions based on disk-logging.
Finally, there are systems that implement transactions inside the kernel. IBM CPR [cpr] and Pilot [pilot] support transactional updates of memory-mapped files. These systems solve problems found in other systems. However, most applications do not use transactions frequently enough to afford the complexity introduced by embedding transaction support in the kernel, making this approach uneconomical.
Herlihy and Moss proposed a transactional memory that is a CPU instruction set designed to support atomic memory updates[herlihy]. Our use of the term is not related to theirs.