diff options
Diffstat (limited to '')
| -rw-r--r-- | www/unlock_notify.html | 492 |
1 files changed, 492 insertions, 0 deletions
diff --git a/www/unlock_notify.html b/www/unlock_notify.html new file mode 100644 index 0000000..17ae69f --- /dev/null +++ b/www/unlock_notify.html @@ -0,0 +1,492 @@ +<!DOCTYPE html> +<html><head> +<meta name="viewport" content="width=device-width, initial-scale=1.0"> +<meta http-equiv="content-type" content="text/html; charset=UTF-8"> +<link href="sqlite.css" rel="stylesheet"> +<title>SQLite Unlock-Notify API</title> +<!-- path= --> +</head> +<body> +<div class=nosearch> +<a href="index.html"> +<img class="logo" src="images/sqlite370_banner.gif" alt="SQLite" border="0"> +</a> +<div><!-- IE hack to prevent disappearing logo --></div> +<div class="tagline desktoponly"> +Small. Fast. Reliable.<br>Choose any three. +</div> +<div class="menu mainmenu"> +<ul> +<li><a href="index.html">Home</a> +<li class='mobileonly'><a href="javascript:void(0)" onclick='toggle_div("submenu")'>Menu</a> +<li class='wideonly'><a href='about.html'>About</a> +<li class='desktoponly'><a href="docs.html">Documentation</a> +<li class='desktoponly'><a href="download.html">Download</a> +<li class='wideonly'><a href='copyright.html'>License</a> +<li class='desktoponly'><a href="support.html">Support</a> +<li class='desktoponly'><a href="prosupport.html">Purchase</a> +<li class='search' id='search_menubutton'> +<a href="javascript:void(0)" onclick='toggle_search()'>Search</a> +</ul> +</div> +<div class="menu submenu" id="submenu"> +<ul> +<li><a href='about.html'>About</a> +<li><a href='docs.html'>Documentation</a> +<li><a href='download.html'>Download</a> +<li><a href='support.html'>Support</a> +<li><a href='prosupport.html'>Purchase</a> +</ul> +</div> +<div class="searchmenu" id="searchmenu"> +<form method="GET" action="search"> +<select name="s" id="searchtype"> +<option value="d">Search Documentation</option> +<option value="c">Search Changelog</option> +</select> +<input type="text" name="q" id="searchbox" value=""> +<input type="submit" value="Go"> +</form> +</div> +</div> +<script> +function toggle_div(nm) { +var w = document.getElementById(nm); +if( w.style.display=="block" ){ +w.style.display = "none"; +}else{ +w.style.display = "block"; +} +} +function toggle_search() { +var w = document.getElementById("searchmenu"); +if( w.style.display=="block" ){ +w.style.display = "none"; +} else { +w.style.display = "block"; +setTimeout(function(){ +document.getElementById("searchbox").focus() +}, 30); +} +} +function div_off(nm){document.getElementById(nm).style.display="none";} +window.onbeforeunload = function(e){div_off("submenu");} +/* Disable the Search feature if we are not operating from CGI, since */ +/* Search is accomplished using CGI and will not work without it. */ +if( !location.origin || !location.origin.match || !location.origin.match(/http/) ){ +document.getElementById("search_menubutton").style.display = "none"; +} +/* Used by the Hide/Show button beside syntax diagrams, to toggle the */ +function hideorshow(btn,obj){ +var x = document.getElementById(obj); +var b = document.getElementById(btn); +if( x.style.display!='none' ){ +x.style.display = 'none'; +b.innerHTML='show'; +}else{ +x.style.display = ''; +b.innerHTML='hide'; +} +return false; +} +var antiRobot = 0; +function antiRobotGo(){ +if( antiRobot!=3 ) return; +antiRobot = 7; +var j = document.getElementById("mtimelink"); +if(j && j.hasAttribute("data-href")) j.href=j.getAttribute("data-href"); +} +function antiRobotDefense(){ +document.body.onmousedown=function(){ +antiRobot |= 2; +antiRobotGo(); +document.body.onmousedown=null; +} +document.body.onmousemove=function(){ +antiRobot |= 2; +antiRobotGo(); +document.body.onmousemove=null; +} +setTimeout(function(){ +antiRobot |= 1; +antiRobotGo(); +}, 100) +antiRobotGo(); +} +antiRobotDefense(); +</script> + + + +<style> + pre a:visited, pre a:link { text-decoration: none ; color: #40534b } + pre { + background: #F3F3F3; + float: right; + padding: 1ex 2ex; + margin-left: 1em; + border: solid black 1px; + } + h1,h2 { clear: both ; text-align: center } +</style> + +<h1>Using the sqlite3_unlock_notify() API</h1> + +<pre> +<span style="color:blue;font-style:italic">/* This example uses the pthreads API */</span> +#include <pthread.h> + +<span style="color:blue;font-style:italic">/*</span> +<span style="color:blue;font-style:italic">** A pointer to an instance of this structure is passed as the user-context</span> +<span style="color:blue;font-style:italic">** pointer when registering for an unlock-notify callback.</span> +<span style="color:blue;font-style:italic">*/</span> +typedef struct UnlockNotification UnlockNotification; +struct UnlockNotification { + int fired; <span style="color:blue;font-style:italic">/* True after unlock event has occurred */</span> + pthread_cond_t cond; <span style="color:blue;font-style:italic">/* Condition variable to wait on */</span> + pthread_mutex_t mutex; <span style="color:blue;font-style:italic">/* Mutex to protect structure */</span> +}; + +<span style="color:blue;font-style:italic">/*</span> +<span style="color:blue;font-style:italic">** This function is an unlock-notify callback registered with SQLite.</span> +<span style="color:blue;font-style:italic">*/</span> +static void unlock_notify_cb(void **apArg, int nArg){ + int i; + for(i=0; i<nArg; i++){ + UnlockNotification *p = (UnlockNotification *)apArg[i]; + pthread_mutex_lock(&p->mutex); + p->fired = 1; + pthread_cond_signal(&p->cond); + pthread_mutex_unlock(&p->mutex); + } +} + +<span style="color:blue;font-style:italic">/*</span> +<span style="color:blue;font-style:italic">** This function assumes that an SQLite API call (either <a href="c3ref/prepare.html">sqlite3_prepare_v2</a>() </span> +<span style="color:blue;font-style:italic">** or <a href="c3ref/step.html">sqlite3_step</a>()) has just returned SQLITE_LOCKED. The argument is the</span> +<span style="color:blue;font-style:italic">** associated database connection.</span> +<span style="color:blue;font-style:italic">**</span> +<span style="color:blue;font-style:italic">** This function calls <a href="c3ref/unlock_notify.html">sqlite3_unlock_notify</a>() to register for an </span> +<span style="color:blue;font-style:italic">** unlock-notify callback, then blocks until that callback is delivered </span> +<span style="color:blue;font-style:italic">** and returns SQLITE_OK. The caller should then retry the failed operation.</span> +<span style="color:blue;font-style:italic">**</span> +<span style="color:blue;font-style:italic">** Or, if <a href="c3ref/unlock_notify.html">sqlite3_unlock_notify</a>() indicates that to block would deadlock </span> +<span style="color:blue;font-style:italic">** the system, then this function returns SQLITE_LOCKED immediately. In </span> +<span style="color:blue;font-style:italic">** this case the caller should not retry the operation and should roll </span> +<span style="color:blue;font-style:italic">** back the current transaction (if any).</span> +<span style="color:blue;font-style:italic">*/</span> +static int wait_for_unlock_notify(<a href="c3ref/sqlite3.html">sqlite3</a> *db){ + int rc; + UnlockNotification un; + + <span style="color:blue;font-style:italic">/* Initialize the UnlockNotification structure. */</span> + un.fired = 0; + pthread_mutex_init(&un.mutex, 0); + pthread_cond_init(&un.cond, 0); + + <span style="color:blue;font-style:italic">/* Register for an unlock-notify callback. */</span> + rc = <a href="c3ref/unlock_notify.html">sqlite3_unlock_notify</a>(db, unlock_notify_cb, (void *)&un); + assert( rc==SQLITE_LOCKED || rc==SQLITE_OK ); + + <span style="color:blue;font-style:italic">/* The call to <a href="c3ref/unlock_notify.html">sqlite3_unlock_notify</a>() always returns either SQLITE_LOCKED </span> +<span style="color:blue;font-style:italic"> ** or SQLITE_OK. </span> +<span style="color:blue;font-style:italic"> **</span> +<span style="color:blue;font-style:italic"> ** If SQLITE_LOCKED was returned, then the system is deadlocked. In this</span> +<span style="color:blue;font-style:italic"> ** case this function needs to return SQLITE_LOCKED to the caller so </span> +<span style="color:blue;font-style:italic"> ** that the current transaction can be rolled back. Otherwise, block</span> +<span style="color:blue;font-style:italic"> ** until the unlock-notify callback is invoked, then return SQLITE_OK.</span> + <span style="color:blue;font-style:italic">*/</span> + if( rc==SQLITE_OK ){ + pthread_mutex_lock(&un.mutex); + if( !un.fired ){ + pthread_cond_wait(&un.cond, &un.mutex); + } + pthread_mutex_unlock(&un.mutex); + } + + <span style="color:blue;font-style:italic">/* Destroy the mutex and condition variables. */</span> + pthread_cond_destroy(&un.cond); + pthread_mutex_destroy(&un.mutex); + + return rc; +} + +<span style="color:blue;font-style:italic">/*</span> +<span style="color:blue;font-style:italic">** This function is a wrapper around the SQLite function <a href="c3ref/step.html">sqlite3_step</a>().</span> +<span style="color:blue;font-style:italic">** It functions in the same way as step(), except that if a required</span> +<span style="color:blue;font-style:italic">** shared-cache lock cannot be obtained, this function may block waiting for</span> +<span style="color:blue;font-style:italic">** the lock to become available. In this scenario the normal API step()</span> +<span style="color:blue;font-style:italic">** function always returns SQLITE_LOCKED.</span> +<span style="color:blue;font-style:italic">**</span> +<span style="color:blue;font-style:italic">** If this function returns SQLITE_LOCKED, the caller should rollback</span> +<span style="color:blue;font-style:italic">** the current transaction (if any) and try again later. Otherwise, the</span> +<span style="color:blue;font-style:italic">** system may become deadlocked.</span> +<span style="color:blue;font-style:italic">*/</span> +int sqlite3_blocking_step(<a href="c3ref/stmt.html">sqlite3_stmt</a> *pStmt){ + int rc; + while( SQLITE_LOCKED==(rc = <a href="c3ref/step.html">sqlite3_step</a>(pStmt)) ){ + rc = wait_for_unlock_notify(<a href="c3ref/db_handle.html">sqlite3_db_handle</a>(pStmt)); + if( rc!=SQLITE_OK ) break; + <a href="c3ref/reset.html">sqlite3_reset</a>(pStmt); + } + return rc; +} + +<span style="color:blue;font-style:italic">/*</span> +<span style="color:blue;font-style:italic">** This function is a wrapper around the SQLite function <a href="c3ref/prepare.html">sqlite3_prepare_v2</a>().</span> +<span style="color:blue;font-style:italic">** It functions in the same way as prepare_v2(), except that if a required</span> +<span style="color:blue;font-style:italic">** shared-cache lock cannot be obtained, this function may block waiting for</span> +<span style="color:blue;font-style:italic">** the lock to become available. In this scenario the normal API prepare_v2()</span> +<span style="color:blue;font-style:italic">** function always returns SQLITE_LOCKED.</span> +<span style="color:blue;font-style:italic">**</span> +<span style="color:blue;font-style:italic">** If this function returns SQLITE_LOCKED, the caller should rollback</span> +<span style="color:blue;font-style:italic">** the current transaction (if any) and try again later. Otherwise, the</span> +<span style="color:blue;font-style:italic">** system may become deadlocked.</span> +<span style="color:blue;font-style:italic">*/</span> +int sqlite3_blocking_prepare_v2( + <a href="c3ref/sqlite3.html">sqlite3</a> *db, <span style="color:blue;font-style:italic">/* Database handle. */</span> + const char *zSql, <span style="color:blue;font-style:italic">/* UTF-8 encoded SQL statement. */</span> + int nSql, <span style="color:blue;font-style:italic">/* Length of zSql in bytes. */</span> + <a href="c3ref/stmt.html">sqlite3_stmt</a> **ppStmt, <span style="color:blue;font-style:italic">/* OUT: A pointer to the prepared statement */</span> + const char **pz <span style="color:blue;font-style:italic">/* OUT: End of parsed string */</span> +){ + int rc; + while( SQLITE_LOCKED==(rc = <a href="c3ref/prepare.html">sqlite3_prepare_v2</a>(db, zSql, nSql, ppStmt, pz)) ){ + rc = wait_for_unlock_notify(db); + if( rc!=SQLITE_OK ) break; + } + return rc; +} +</pre> + + +<p> + When two or more connections access the same database in shared-cache + mode, read and write (shared and exclusive) locks on individual tables + are used to ensure that concurrently executing transactions are kept + isolated. Before writing to a table, a write (exclusive) lock must be + obtained on that table. Before reading, a read (shared) lock must be + obtained. A connection releases all held table locks when it concludes + its transaction. If a connection cannot obtain a required lock, then + the call to <a href="c3ref/step.html">sqlite3_step()</a> returns SQLITE_LOCKED. + +<p> + Although it is less common, a call to <a href="c3ref/prepare.html">sqlite3_prepare()</a> or + <a href="c3ref/prepare.html">sqlite3_prepare_v2()</a> may also return SQLITE_LOCKED if it cannot obtain + a read-lock on the <a href="schematab.html">sqlite_schema table</a> of each attached database. These + APIs need to read the schema data contained in the sqlite_schema table + in order to compile SQL statements to <a href="c3ref/stmt.html">sqlite3_stmt*</a> objects. + +<p> + This article presents a technique using the SQLite <a href="c3ref/unlock_notify.html">sqlite3_unlock_notify()</a> + interface such that calls to <a href="c3ref/step.html">sqlite3_step()</a> and <a href="c3ref/prepare.html">sqlite3_prepare_v2()</a> + block until the required locks are available instead of returning + SQLITE_LOCKED immediately. If the + sqlite3_blocking_step() or sqlite3_blocking_prepare_v2() functions presented + to the left return SQLITE_LOCKED, this indicates that to block would + deadlock the system. + +<p> + The <a href="c3ref/unlock_notify.html">sqlite3_unlock_notify()</a> API, which is only available if the library is + compiled with the pre-processor symbol <a href="compile.html#enable_unlock_notify">SQLITE_ENABLE_UNLOCK_NOTIFY</a> defined, + is <a href="c3ref/unlock_notify.html">documented here</a>. This article is not a + substitute for reading the full API documentation! + +<p> + The <a href="c3ref/unlock_notify.html">sqlite3_unlock_notify()</a> interface is designed for use in systems + that have a separate thread assigned to each <a href="c3ref/sqlite3.html">database connection</a>. There + is nothing in the implementation that prevents a single thread from running + multiple database connections. However, the <a href="c3ref/unlock_notify.html">sqlite3_unlock_notify()</a> + interface only works on a single connection at a time, so the lock + resolution logic presented here will only work for a single + database connection per thread. + +<p><b>The sqlite3_unlock_notify() API</b> + +<p> + After a call to <a href="c3ref/step.html">sqlite3_step()</a> or <a href="c3ref/prepare.html">sqlite3_prepare_v2()</a> returns + SQLITE_LOCKED, the <a href="c3ref/unlock_notify.html">sqlite3_unlock_notify()</a> API may be invoked to register + for an unlock-notify callback. The unlock-notify callback is invoked by + SQLite after the database connection holding the table-lock that prevented + the call to <a href="c3ref/step.html">sqlite3_step()</a> or <a href="c3ref/prepare.html">sqlite3_prepare_v2()</a> from succeeding has + finished its transaction and released all locks. For example, if a call to + sqlite3_step() is an attempt to read from table X, and some other connection + Y is holding a write-lock on table X, then sqlite3_step() will return + SQLITE_LOCKED. If <a href="c3ref/unlock_notify.html">sqlite3_unlock_notify()</a> is then called, the unlock-notify + callback will be invoked after connection Y's transaction is concluded. The + connection that the unlock-notify callback is waiting on, in this case + connection Y, is known as the "blocking connection". + +<p> + If a call to sqlite3_step() that attempts to write to a database table + returns SQLITE_LOCKED, then more than one other connection may be holding + a read-lock on the database table in question. In this case SQLite simply + selects one of those other connections arbitrarily and issues the + unlock-notify callback when that connection's transaction is finished. + Whether the call to sqlite3_step() was blocked by one or many connections, + when the corresponding unlock-notify callback is issued it is not + guaranteed that the required lock is available, only that it may be. + +<p> + When the unlock-notify callback is issued, it is issued from within a + call to sqlite3_step() (or sqlite3_close()) associated with the blocking + connection. It is illegal to invoke any sqlite3_XXX() API functions from + within an unlock-notify callback. The expected use is that the unlock-notify + callback will signal some other waiting thread or schedule some action + to take place later. + +<p> + The algorithm used by the sqlite3_blocking_step() function is as follows: + +<ol> + <li><p> Call sqlite3_step() on the supplied statement handle. If the call + returns anything other than SQLITE_LOCKED, then return this value + to the caller. Otherwise, continue. + + <li><p> Invoke <a href="c3ref/unlock_notify.html">sqlite3_unlock_notify()</a> on the database connection handle + associated with the supplied statement handle to register for an + unlock-notify callback. If the call to unlock_notify() returns + SQLITE_LOCKED, then return this value to the caller. + + <li><p> Block until the unlock-notify callback is invoked by another thread. + + <li><p> Call sqlite3_reset() on the statement handle. Since an + SQLITE_LOCKED error may only occur on the first call to sqlite3_step() + (it is not possible for one call to sqlite3_step() to return + SQLITE_ROW and then the next SQLITE_LOCKED), the statement handle may + be reset at this point without affecting the results of the query + from the point of view of the caller. If sqlite3_reset() were not + called at this point, the next call to sqlite3_step() would return + SQLITE_MISUSE. + + <li><p> Return to step 1. +</ol> + +<p> + The algorithm used by the sqlite3_blocking_prepare_v2() function is similar, + except that step 4 (resetting the statement handle) is omitted. + + +<p><b>Writer Starvation</b> + +<p> + Multiple connections may hold a read-lock simultaneously. If many threads + are acquiring overlapping read-locks, it might be the case that at least + one thread is always holding a read lock. + Then a table waiting for a write-lock will wait forever. + This scenario is called "writer starvation." + +<p> + SQLite helps applications avoid writer starvation. After any attempt to + obtain a write-lock on a table fails (because one or more other + connections are holding read-locks), all attempts to open new transactions + on the shared-cache fail until one of the following is true: + +<ul> + <li> The current writer concludes its transaction, OR + <li> The number of open read-transactions on the shared-cache drops to zero. +</ul> + +<p> + Failed attempts to open new read-transactions return SQLITE_LOCKED to the + caller. If the caller then calls <a href="c3ref/unlock_notify.html">sqlite3_unlock_notify()</a> to register for + an unlock-notify callback, the blocking connection is the connection that + currently has an open write-transaction on the shared-cache. This prevents + writer-starvation since if no new read-transactions may be opened and + assuming all existing read-transactions are eventually concluded, the + writer will eventually have an opportunity to obtain the required + write-lock. + +<p><b>The pthreads API</b> + + <p> By the time <a href="c3ref/unlock_notify.html">sqlite3_unlock_notify()</a> is invoked by + wait_for_unlock_notify(), it is possible that the blocking connection + that prevented the sqlite3_step() or sqlite3_prepare_v2() call from + succeeding has already finished its transaction. In this case, the + unlock-notify callback is invoked immediately, before + <a href="c3ref/unlock_notify.html">sqlite3_unlock_notify()</a> returns. Or, it is possible that the + unlock-notify callback is invoked by a second thread after + <a href="c3ref/unlock_notify.html">sqlite3_unlock_notify()</a> is called but before the thread starts waiting + to be asynchronously signaled. + + <p> Exactly how such a potential race-condition is handled depends on the + threads and synchronization primitives interface used by the application. + This example uses pthreads, the interface provided by modern UNIX-like + systems, including Linux. + + <p> The pthreads interface provides the pthread_cond_wait() function. + This function allows the caller to simultaneously release a mutex + and start waiting for an asynchronous signal. Using this function, + a "fired" flag and a mutex, the race-condition described above may + be eliminated as follows: + + <p> When the unlock-notify callback is invoked, which may be before the + thread that called <a href="c3ref/unlock_notify.html">sqlite3_unlock_notify()</a> begins waiting for the + asynchronous signal, it does the following: + + <ol> + <li> Obtains the mutex. + <li> Sets the "fired" flag to true. + <li> Attempts to signal a waiting thread. + <li> Releases the mutex. + </ol> + + <p> When the wait_for_unlock_notify() thread is ready to begin waiting for + the unlock-notify callback to arrive, it: + + <ol> + <li> Obtains the mutex. + <li> Checks if the "fired" flag has been set. If so, the unlock-notify + callback has already been invoked. Release the mutex and continue. + <li> Atomically releases the mutex and begins waiting for the + asynchronous signal. When the signal arrives, continue. + </ol> + + <p> This way, it doesn't matter if the unlock-notify callback has already + been invoked, or is being invoked, when the wait_for_unlock_notify() + thread begins blocking. + +<p><b>Possible Enhancements</b> + + <p> The code in this article could be improved in at least two ways: + + <ul> + <li> It could manage thread priorities. + <li> It could handle a special case of SQLITE_LOCKED that can occur + when dropping a table or index. + </ul> + + <p> + Even though the <a href="c3ref/unlock_notify.html">sqlite3_unlock_notify()</a> function only allows the caller + to specify a single user-context pointer, an unlock-notify callback + is passed an array of such context pointers. This is because if when + a blocking connection concludes its transaction, if there is more + than one unlock-notify registered to call the same C function, the + context-pointers are marshaled into an array and a single callback + issued. If each thread were assigned a priority, then instead of just + signaling the threads in arbitrary order as this implementation does, + higher priority threads could be signaled before lower priority threads. + + <p> + If a "DROP TABLE" or "DROP INDEX" SQL command is executed, and the + same database connection currently has one or more actively + executing SELECT statements, then SQLITE_LOCKED is returned. If + <a href="c3ref/unlock_notify.html">sqlite3_unlock_notify()</a> is called in this case, then the specified + callback will be invoked immediately. Re-attempting the "DROP + TABLE" or "DROP INDEX" statement will return another SQLITE_LOCKED + error. In the implementation of sqlite3_blocking_step() shown to the + left, this could cause an infinite loop. + + <p> + The caller could distinguish between this special "DROP TABLE|INDEX" + case and other cases by using <a href="rescode.html#extrc">extended error codes</a>. When it is appropriate + to call <a href="c3ref/unlock_notify.html">sqlite3_unlock_notify()</a>, the extended error code is + SQLITE_LOCKED_SHAREDCACHE. Otherwise, in the "DROP TABLE|INDEX" case, + it is just plain SQLITE_LOCKED. Another solution might be to limit + the number of times that any single query could be reattempted (to say + 100). Although this might be less efficient than one might wish, the + situation in question is not likely to occur often. + +<div style="clear:both"></div> +<p align="center"><small><i>This page last modified on <a href="https://sqlite.org/docsrc/honeypot" id="mtimelink" data-href="https://sqlite.org/docsrc/finfo/pages/unlock_notify.in?m=490fe965003324fd8">2020-06-19 13:05:24</a> UTC </small></i></p> + |