Browse Prior Art Database

Accessing Object-Orientated Operating System Locks

IP.com Disclosure Number: IPCOM000117641D
Original Publication Date: 1996-Apr-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 2 page(s) / 79K

Publishing Venue

IBM

Related People

Platt, MW: AUTHOR [+2]

Abstract

Modern multiprocessing operating systems contain a scheduler table which associates with each process that exists at any given time information about the "state" of the process: whether it is ready to run, running, or blocked waiting for completion of Input/Output (I/O) or (in the case of message-passing operating systems such as microkernels) blocked pending the arrival of a message. This is, in effect, a kernel lock table.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Accessing Object-Orientated Operating System Locks

      Modern multiprocessing operating systems contain a scheduler
table which associates with each process that exists at any given
time information about the "state" of the process:  whether it is
ready to run, running, or blocked waiting for completion of
Input/Output (I/O) or (in the case of message-passing operating
systems such as microkernels) blocked pending the arrival of a
message.  This is, in effect, a kernel lock table.

      A number of "application-enabling" systems such as On-Line
Transaction Processing (OLTP) transaction monitors and Database
Management Systems (DBMS) make extensive use of locking mechanisms to
provide protection of data during concurrent access, and
synchronization.  Such systems typically implement their own lock
manager as a user process which makes use of the operating system's
atomic locking mechanisms.

      Processes in the Transaction Monitor or DBMS may become blocked
either because they are waiting for an I/O completion or for a system
resource to become available, OR because they are unable to access a
piece of data because one of the application-level locks in the lock
manager is held by another process and the process must inform the
scheduler in the operating system that it is to be de-scheduled.  The
two sets of locks are kept in synchronization by various ad-hoc
methods, which involve considerable processing overhead.

      This disparity of location between what are, essentially, the
same kinds of blocking lock (some in the operating system scheduler
tables, and some in the user-level lock manager) causes great
inefficiency in performance of the system.  This is mainly because
the scheduler can only act on what it is told to do by the
application at a very coarse level:  a given process is either
blocked or not.

      This problem is addressed in the system described here by
moving the operating system's scheduler table from the kernel memory
to the user-space memory.  The table is held in...