mirror of
https://github.com/yasuhirokimura/db18
synced 2026-06-08 18:29:23 +00:00
141 lines
5.5 KiB
HTML
141 lines
5.5 KiB
HTML
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
|
||
<title>Standard lock modes</title>
|
||
<link rel="stylesheet" href="gettingStarted.css" type="text/css" />
|
||
<meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
|
||
<link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" />
|
||
<link rel="up" href="lock.html" title="Chapter 17. The Locking Subsystem" />
|
||
<link rel="prev" href="lock_max.html" title="Configuring locking: sizing the system" />
|
||
<link rel="next" href="lock_dead.html" title="Deadlock detection" />
|
||
</head>
|
||
<body>
|
||
<div xmlns="" class="navheader">
|
||
<div class="libver">
|
||
<p>Library Version 18.1.40</p>
|
||
</div>
|
||
<table width="100%" summary="Navigation header">
|
||
<tr>
|
||
<th colspan="3" align="center">Standard lock modes</th>
|
||
</tr>
|
||
<tr>
|
||
<td width="20%" align="left"><a accesskey="p" href="lock_max.html">Prev</a> </td>
|
||
<th width="60%" align="center">Chapter 17. The Locking Subsystem </th>
|
||
<td width="20%" align="right"> <a accesskey="n" href="lock_dead.html">Next</a></td>
|
||
</tr>
|
||
</table>
|
||
<hr />
|
||
</div>
|
||
<div class="sect1" lang="en" xml:lang="en">
|
||
<div class="titlepage">
|
||
<div>
|
||
<div>
|
||
<h2 class="title" style="clear: both"><a id="lock_stdmode"></a>Standard lock modes</h2>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>
|
||
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 <span class="bold"><strong>db_lockmode_t</strong></span>,
|
||
which is the type of a lock mode within a conflict matrix.
|
||
</p>
|
||
<p>
|
||
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.
|
||
</p>
|
||
<div class="variablelist">
|
||
<dl>
|
||
<dt>
|
||
<span class="term">DB_LOCK_NG</span>
|
||
</dt>
|
||
<dd>not granted (always 0)</dd>
|
||
<dt>
|
||
<span class="term">DB_LOCK_READ</span>
|
||
</dt>
|
||
<dd>read (shared)</dd>
|
||
<dt>
|
||
<span class="term">DB_LOCK_WRITE</span>
|
||
</dt>
|
||
<dd>write (exclusive)</dd>
|
||
<dt>
|
||
<span class="term">DB_LOCK_IWRITE</span>
|
||
</dt>
|
||
<dd>intention to write (shared)</dd>
|
||
<dt>
|
||
<span class="term">DB_LOCK_IREAD</span>
|
||
</dt>
|
||
<dd>intention to read (shared)</dd>
|
||
<dt>
|
||
<span class="term">DB_LOCK_IWR</span>
|
||
</dt>
|
||
<dd>intention to read and write (shared)</dd>
|
||
</dl>
|
||
</div>
|
||
<p>
|
||
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.
|
||
</p>
|
||
<pre class="programlisting"> Notheld Read Write IWrite IRead IRW
|
||
Notheld 0 0 0 0 0 0
|
||
Read* 0 0 1 1 0 1
|
||
Write** 0 1 1 1 1 1
|
||
Intent Write 0 1 1 0 0 0
|
||
Intent Read 0 0 1 0 0 0
|
||
Intent RW 0 1 1 0 0 0</pre>
|
||
<div class="variablelist">
|
||
<dl>
|
||
<dt>
|
||
<span class="term">*</span>
|
||
</dt>
|
||
<dd>
|
||
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.
|
||
</dd>
|
||
<dt>
|
||
<span class="term">**</span>
|
||
</dt>
|
||
<dd>
|
||
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.
|
||
</dd>
|
||
</dl>
|
||
</div>
|
||
</div>
|
||
<div class="navfooter">
|
||
<hr />
|
||
<table width="100%" summary="Navigation footer">
|
||
<tr>
|
||
<td width="40%" align="left"><a accesskey="p" href="lock_max.html">Prev</a> </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="u" href="lock.html">Up</a>
|
||
</td>
|
||
<td width="40%" align="right"> <a accesskey="n" href="lock_dead.html">Next</a></td>
|
||
</tr>
|
||
<tr>
|
||
<td width="40%" align="left" valign="top">Configuring locking: sizing the
|
||
system </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="h" href="index.html">Home</a>
|
||
</td>
|
||
<td width="40%" align="right" valign="top"> Deadlock detection</td>
|
||
</tr>
|
||
</table>
|
||
</div>
|
||
</body>
|
||
</html>
|