> I don't want per-say to remove my pthread_rwlock() but the main point of this 
> discussion is I should not have to use pthread_rwlock().

I'd say pthread_rwlock and SQLite-specific mechanisms work completely
differently and you should choose depending on what you want to do. As
you saw to use SQLite's mechanisms you should write additional code
waiting when write lock is released. As you said it's not effective
and prone to starvation. But it works across process boundaries when
pthread_rwlock works only inside your process although it does all
waiting very effectively on a kernel level.
So if you will ever want to connect to your database with sqlite3
command line tool for example while your application is running, and
you will do some manipulations with the database, then your
pthread_rwlock won't work and you will still get SQLITE_BUSY. And now
you decide what mechanism is better for you.


Pavel


On Tue, May 24, 2011 at 10:11 AM, John Deal <bassd...@yahoo.com> wrote:
> Hello Pavel,
>
> I don't want per-say to remove my pthread_rwlock() but the main point of this 
> discussion is I should not have to use pthread_rwlock().  Others have 
> mentioned I should be using SQLite-specific mechanisms to achieve the same 
> results.  I am just trying to understand how to do that.  Pthread_rwlock() 
> works fine.
>
> Thanks,
>
> John
>
> --- On Tue, 5/24/11, Pavel Ivanov <paiva...@gmail.com> wrote:
>
>> From: Pavel Ivanov <paiva...@gmail.com>
>> Subject: Re: [sqlite] Multi-threading Common Problem
>> To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org>
>> Date: Tuesday, May 24, 2011, 9:51 AM
>> > I have all writes in
>> transactions.  If I deactivate my pthread_rwlock() that
>> enforce the above, several writes fail with a "database
>> locked" error (I assume it is returning SQLITE_BUSY).
>> >
>> > So how do I implement the equivalent of a
>> pthread_rwlock() using SQLite mechinisms?
>>
>> When SQLITE_BUSY in a reader transaction is returned just
>> wait a
>> little bit and try again. Also you can benefit from
>> sqlite3_busy_timeout (http://www.sqlite.org/c3ref/busy_timeout.html).
>>
>> Another question is why do you want to get read of
>> pthread_rwlock if
>> it works for you?
>>
>>
>> Pavel
>>
>>
>> On Tue, May 24, 2011 at 7:43 AM, John Deal <bassd...@yahoo.com>
>> wrote:
>> > Hello Roger,
>> >
>> > Sorry to be so brain-dead but I am still confused.  I
>> have multiple threads, each with their own DB connection.
>>  I want to allow multiple readers accessing the DB at the
>> same time since nothing is changing.  However, if a writes
>> is to take place, I want all readers to finish their reads
>> and give the writer exclusive access.  Once the writer is
>> done, the readers can come back in.
>> >
>> > I have all writes in transactions.  If I deactivate
>> my pthread_rwlock() that enforce the above, several writes
>> fail with a "database locked" error (I assume it is
>> returning SQLITE_BUSY).  With my pthread_rwlock(), I have
>> multiple threads reading the DB and my writes get the
>> exclusive access they need.  Now I could loop on the write
>> until it gets in but that seems very wasteful.
>> >
>> > So how do I implement the equivalent of a
>> pthread_rwlock() using SQLite mechinisms?
>> >
>> > Thanks,
>> >
>> > John
>> >
>> > --- On Tue, 5/24/11, Roger Binns <rog...@rogerbinns.com>
>> wrote:
>> >
>> >> From: Roger Binns <rog...@rogerbinns.com>
>> >> Subject: Re: [sqlite] Multi-threading Common
>> Problem
>> >> To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org>
>> >> Date: Tuesday, May 24, 2011, 3:10 AM
>> >> -----BEGIN PGP SIGNED MESSAGE-----
>> >> Hash: SHA1
>> >>
>> >> On 05/23/2011 09:12 PM, John Deal wrote:
>> >> > I guess I am lost on how to obtain a many
>> reader or
>> >> one writer mutex in SQLite.
>> >>
>> >> You are confusing locks on the database and locks
>> in the
>> >> library on a
>> >> sqlite3 pointer.  The latter is what the mutex
>> alloc
>> >> function you reference
>> >> is about and there there is no reader/writer
>> >> mechanism.  Access has to be
>> >> serialized.
>> >>
>> >> > You are correct in the locking article
>> referenced I
>> >> want a mutex that can have the lock states of
>> shared,
>> >> pending, and exclusive.
>> >>
>> >> Those are locks on the database which you get
>> through
>> >> regular operations and
>> >> transactions.
>> >>
>> >> Roger
>> >> -----BEGIN PGP SIGNATURE-----
>> >> Version: GnuPG v1.4.11 (GNU/Linux)
>> >>
>> >>
>> iEYEARECAAYFAk3bWeIACgkQmOOfHg372QQf8QCgjlawQMJWJ1I3/6OqMkczXswk
>> >> VWQAmgLzGifXbh9UJpuEdUTTZl8e8xYp
>> >> =rXCY
>> >> -----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
>> >
>> _______________________________________________
>> 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
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to