Hello Roger, Sorry for the long delay. I did not see this in the swamp of recent email.
I guess I am lost on how to obtain a many reader or one writer mutex in SQLite. I interpret the mutex returned by sqlite3_mutex_alloc() as being an exclusive mutex since the documentation states "The sqlite3_mutex_enter() and sqlite3_mutex_try() routines attempt to enter a mutex. If another thread is already within the mutex, sqlite3_mutex_enter() will block and sqlite3_mutex_try() will return SQLITE_BUSY." If I interpret this correctly, this is to ensure serial access to the DB in a multi-connection/multi-thread environment. It seems if a recursive mutex is requested, the same thread can enter the mutex multiple times if it also frees the mutex the same amount of time. I don't understand how to implement a multi-reader or one writer mutex with sqlite3_mutex_alloc(). Should I be looking at something else? You are correct in the locking article referenced I want a mutex that can have the lock states of shared, pending, and exclusive. In other words, the same functionality as a pthread_rwlock() OS call. How do I get this? Sorry if I am missing something obvious. Thanks, John --- On Fri, 5/13/11, Roger Binns <rog...@rogerbinns.com> wrote: > From: Roger Binns <rog...@rogerbinns.com> > Subject: Re: [sqlite] Multi-threading Common Problem > To: sqlite-users@sqlite.org > Date: Friday, May 13, 2011, 2:00 AM > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/12/2011 01:26 PM, John Deal wrote: > > Good question. Very possible my understanding is > not complete. > > This document has the full details: > > http://www.sqlite.org/lockingv3.html > > >I have basically read and write transactions, each > potentially with several accesses to the DB. > >I want to ensure that if a write transaction is > happening, no read > transactions are in progress > > You do know you can use transactions for > reads? Or use multiple database > connections to get isolation. If you worry about the > efficiency of the > latter then don't - ie get your code correct and then worry > about > performance. I recommend against the use of shared > cache mode on general > purpose computers (as opposed to embedded devices with > trivial amounts of > memory) because it changes some API behaviour (especially > busy handling) and > the amount of memory "wasted" is a rounding error. > > In any event it looks like I am not understanding some > deeper aspect of what > you are doing. My underlying point remains - there is > absolutely no need to > remove or workaround SQLite's builtin mutexes. They > ensure that threaded > code does not screw things up and are thoroughly > tested/developed. > > Any question that starts with "so I > removed/changed/subverted SQLite's > existing mutexes" will be followed with a response where > you'll need to > prove that doing so isn't the cause. > > It is ok to augment them with your own locking but even > that should not be > necessary. > > Roger > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk3MyPkACgkQmOOfHg372QTTXgCcCa2bDbYH9WKQ2J2fPYhKLHPX > DBgAoLoj+uRJ3GDIHWGU7TfgNXxDAuAH > =exlM > -----END PGP SIGNATURE----- > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
