Skip Navigation

The Computer Journal 1998 41(2):84-97; doi:10.1093/comjnl/41.2.84
© 1998 by British Computer Society
This Article
Right arrow Full Text (PDF)
Right arrow Alert me when this article is cited
Right arrow Alert me if a correction is posted
Services
Right arrow Email this article to a friend
Right arrow Similar articles in this journal
Right arrow Similar articles in ISI Web of Science
Right arrow Alert me to new issues of the journal
Right arrow Add to My Personal Archive
Right arrow Download to citation manager
Right arrowRequest Permissions
Google Scholar
Right arrow Articles by Bodorik, P.
Right arrow Articles by Jutla, D.
Right arrow Search for Related Content
Social Bookmarking
Add to CiteULike   Add to Connotea   Add to Del.icio.us  
What's this?

Multi-View Memory Support to Operating Systems in Locking for Transaction and Database Systems

P. Bodorik1 and D. Jutla2

1 Faculty of Computer Science, DalTech, Dalhousie University, PO Box 1000, Halifax, Nova Scotia B3J 2X4, Canada Email: bodorik{at}cs.dal.ca, 2 Department of Finance and Management Science, Faculty of Commerce, Saint Mary's University, Halifax, Nova Scotia, Canada

Database (DB) and transaction processing systems utilize their own locking of data items instead of using locking services provided by operating systems (OSs). There are two major reasons for this, one deals with the size of lockable items while the other one with efficiency: (i) OSs provide efficient locking of pages by utilizing the Memory Management Unit. The problem is that the system page size is much too large for locking in transaction or DB systems. (ii) Invocation of OS locking services by applications results in context switching, and in many systems in heavy weight context switching, thus greatly reducing efficiency. The focus of this paper is to investigate the use of the Multi-View Memory (MVM) model and its supporting architecture in providing efficient locking services for transaction processing or DB systems. The model provides for enforcement of access-control protocols through finite-state machine (FSM) specification on units of data that can vary in size from one region of memory to another. The locking protocol is specified by an FSM definition and thus facilitates locking of variable-sized data items by threads executing transactions. Threads executing transactions do not explicitly request locks on data items—they simply access the data items while locking is performed automatically and in many instances without software intervention. This is facilitated by hardware assistance in that the FSM definitions and lock unit state information are stored in caches. Only when a thread is suspended are the state changes communicated to the software lock manager. Delays for lock acquisitions through the MVM model architecture are determined and compared with delays due to lock acquisition by a conventional lock manager.

Received April 7, 1997. revised February 13, 1998.


Add to CiteULike CiteULike   Add to Connotea Connotea   Add to Del.icio.us Del.icio.us    What's this?




Disclaimer:
Please note that abstracts for content published before 1996 were created through digital scanning and may therefore not exactly replicate the text of the original print issues. All efforts have been made to ensure accuracy, but the Publisher will not be held responsible for any remaining inaccuracies. If you require any further clarification, please contact our Customer Services Department.