Showing papers on "Transactional memory published in 1998"
27 Apr 1998
TL;DR: In this article, the authors present a transactional toolkit for the web that allows transactional applications to span Web browsers and servers and supports application specific customisation, so that an application can be made transactional without compromising the security policies operational at browsers.
Abstract: The Web frequently suffers from failures which affect the performance and consistency of applications run over it. An important fault-tolerance technique is the use of atomic transactions for controlling operations on services. While it has been possible to make server-side Web applications transactional, browsers typically did not possess such facilities. However, with the advent of Java it is now possible to consider empowering browsers so that they can fully participate within transactional applications. In this paper we present the design and implementation of a standards compliant transactional toolkit for the Web. The toolkit allows transactional applications to span Web browsers and servers and supports application specific customisation, so that an application can be made transactional without compromising the security policies operational at browsers and servers.
25 citations
Proceedings Article•
15 Jun 1998TL;DR: It is discussed how the extension structure of Rhino can solve performance problems previously unavoidable in traditional systems, and its benefits are quantified.
Abstract: This paper describes Rhino, a transactional memory service implemented on top of the SPIN operating system. Rhino is implemented as an extension that runs in SPIN kernel's address space. We discuss how the extension structure of Rhino can solve performance problems previously unavoidable in traditional systems, and we quantify its benefits. We also introduce three alternative buffer management schemes and study their performance under various workloads.
9 citations
TL;DR: Although precise numbers are lacking, statistics suggest that the number of concurrent programmers has sky-rocketed over the past few years and will continue to do so, mainly from Java's emergence-it's the first ubiquitous concurrent programming language.
Abstract: Although precise numbers are lacking, statistics suggest that the number of concurrent programmers has sky-rocketed over the past few years and will continue to do so. This stems mainly from Java's emergence-it's the first ubiquitous concurrent programming language. The rise in concurrent programmers also reflects an increased use of common C++ multithreaded class libraries and frameworks, Posix pthread library standardization, and other wide spectrum concurrent languages. Although only a small proportion of code found in today's production programs, applications, and systems directly exploits concurrency, every programmer should at least be aware of concurrency.
2 citations