From 780b92ada9afcf1d58085a83a0b9e6bc982203d1 Mon Sep 17 00:00:00 2001 From: Lorry Tar Creator Date: Tue, 17 Feb 2015 17:25:57 +0000 Subject: Imported from /home/lorry/working-area/delta_berkeleydb/db-6.1.23.tar.gz. --- docs/programmer_reference/lock_stdmode.html | 62 ++++++++++++++++++----------- 1 file changed, 38 insertions(+), 24 deletions(-) (limited to 'docs/programmer_reference/lock_stdmode.html') diff --git a/docs/programmer_reference/lock_stdmode.html b/docs/programmer_reference/lock_stdmode.html index 243574f9..921405a3 100644 --- a/docs/programmer_reference/lock_stdmode.html +++ b/docs/programmer_reference/lock_stdmode.html @@ -14,7 +14,7 @@

Library Version 11.2.5.3

Library Version 12.1.6.1

@@ -22,9 +22,7 @@ - +

Prev	Chapter 16. - The Locking Subsystem -	Chapter 16. The Locking Subsystem	Next

@@ -38,16 +36,22 @@

The Berkeley DB locking protocol is described by a conflict matrix. A -conflict matrix is an NxN array in which N is the number of different -lock modes supported, and the (i, j)th entry of the array indicates -whether a lock of mode i conflicts with a lock of mode j. In addition, -Berkeley DB defines the type db_lockmode_t, which is the type of a -lock mode within a conflict matrix.

The following is an example of a conflict matrix. The actual conflict -matrix used by Berkeley DB to support the underlying access methods is more -complicated, but this matrix shows the lock mode relationships available -to applications using the Berkeley DB Locking subsystem interfaces directly.

+ The Berkeley DB locking protocol is described by a conflict + matrix. A conflict matrix is an NxN array in which N is the + number of different lock modes supported, and the (i, j)th + entry of the array indicates whether a lock of mode i + conflicts with a lock of mode j. In addition, Berkeley DB + defines the type db_lockmode_t, + which is the type of a lock mode within a conflict matrix. +

+ The following is an example of a conflict matrix. The actual + conflict matrix used by Berkeley DB to support the underlying + access methods is more complicated, but this matrix shows the + lock mode relationships available to applications using the + Berkeley DB Locking subsystem interfaces directly. +

@@ -76,10 +80,13 @@ to applications using the Berkeley DB Locking subsystem interfaces directly.: intention to read and write (shared)

In a conflict matrix, the rows indicate the lock that is held, and the -columns indicate the lock that is requested. A 1 represents a conflict -(that is, do not grant the lock if the indicated lock is held), and a -0 indicates that it is OK to grant the lock.

+ In a conflict matrix, the rows indicate the lock that is + held, and the columns indicate the lock that is requested. A 1 + represents a conflict (that is, do not grant the lock if the + indicated lock is held), and a 0 indicates that it is OK to + grant the lock. +

               Notheld    Read    Write    IWrite    IRead    IRW
 Notheld           0         0       0         0         0      0
 Read*             0         0       1         1         0      1
@@ -92,14 +99,20 @@ Intent RW         0         1       1         0         0      0

In this case, suppose that there is a read lock held on an object. A new -request for a read lock would be granted, but a request for a write lock -would not.

+ In this case, suppose that there is a read lock + held on an object. A new request for a read lock would + be granted, but a request for a write lock would + not. +

In this case, suppose that there is a write lock held on an object. A -new request for either a read or write lock would be denied.

+ In this case, suppose that there is a write lock + held on an object. A new request for either a read or + write lock would be denied. +

@@ -114,7 +127,8 @@ new request for either a read or write lock would be denied. Next - Configuring locking: sizing the system + Configuring locking: sizing the + system Home -- cgit v1.2.1