Browse Prior Art Database

Delegated locking

IP.com Disclosure Number: IPCOM000032465D
Original Publication Date: 2004-Nov-05
Included in the Prior Art Database: 2004-Nov-05
Document File: 2 page(s) / 40K

Publishing Venue

IBM

Abstract

This article describes a locking system that can improve the locking efficiency of a multi-threaded system where objects or records are frequently read, but where some write operations can hold the lock for a long time. It does this without requiring a redesign of the locking system, or requiring new locks be introduced with smaller granularity. It uses a new combination of optimistic and exclusive locking between different categories of operations, called 'delegated locking'.

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

Page 1 of 2

Delegated locking

This locking system is ideal for improving the performance of existing systems where significant design changes would entail too much risk or effort.

     The idea assumes that at times the system becomes held up by a long-write operation which holds the lock for an object or record, thus holding up fast read operations. It requires that the fields of the record that will be changed by the long-write operation are known at the time the long-write lock is taken. The locking system allows readers that only require fields that are not being changed by the long-write operation to proceed during a long-write, and it does this without requiring a re-design of the locking system. Note that if it was known in advance that certain short-readers would only need access to fields that long-writers would not change, an efficient locking system could be designed to allow this without using this idea. This idea allows this efficiency to be gained once a locking system is already in place.

     It achieves this by 'delegating' the locking to the thread carrying out long-write operation: the reader know that no other write operation can intefere with the fields that they are reading because the long-write operation holds the lock for the object. So, the readers can proceed without taking the lock. However, they must check before returning the required data that the long-write operation had not completed, and a new, conflicting short-writer had not started, while they were reading the data. In this way, readers can proceed with reading fields that are not changed by the long-write operation without changing the locking system.

The algorithm is described here:

Count A: Initially 0. Odd value means short write is taking plac...