Re: [sqlite] single gdbconn object with multiple threads.

[Simon Slavin]

On 24 Jul 2012, at 6:58am, Durga D  wrote:

> My Req. is: I have to write a wrapper for sqlite3. This wrapper will be
> called by different clients from different threads within the process.
> Requests might be read or write. Wrapper will have static sqlite3*. So all
> clients shares the same sqlite3*. To simulate this, I created this sample
> application.
> 
> doubt: How can I achieve this single thread when multiple clients are
> called.

Because you are starting off with different threads it doesn't matter in this 
case.  You have already organised your client into threads so just continue to 
use the threads that you already have.

We sometimes get questions from people who have made individual threads in 
their program only because they think it will speed up SQLite processing.  This 
is a waste for SQLite because it locks the whole database anyway.  But your 
application uses individual threads for a different reason, and SQLite will 
also handle that okay providing that you haven't messed with anything mentioned 
here:



It won't be much faster or slower than doing all your access using a single 
thread.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] single gdbconn object with multiple threads.

[Durga D]

Thank you Simon/Igor.

I got the answer.

>>But since all the work is serialized, a single thread that does all the
reading and writing would be just as fast, if not slightly faster.

How can I achieve this with single thread?

My Req. is: I have to write a wrapper for sqlite3. This wrapper will be
called by different clients from different threads within the process.
Requests might be read or write. Wrapper will have static sqlite3*. So all
clients shares the same sqlite3*. To simulate this, I created this sample
application.

doubt: How can I achieve this single thread when multiple clients are
called.

Am I right?

Regards,

On Mon, Jul 23, 2012 at 8:19 PM, Igor Tandetnik  wrote:

> On 7/23/2012 10:30 AM, Durga D wrote:
>
>> Unless your threads do something else in parallel, you could just as well

>>> do all SQLite work on a single thread
>>
>> doubt: all are parallel threads. started at same time. one thread is
>> writing and others are reading at the same time by using same sqlite3*.
>>
>
> Not really. What really happens is, one of the threads does some work,
> while the other three are sitting waiting on a mutex.
>
>
>  In this scenario, all are parallel.
>>
>
> Again - every SQLite API call acquires a mutex associated with the
> connection. If that mutex is already taken, then the thread sits there
> waiting for it to be released. In other words, two SQLite calls on the same
> connection never execute at the same time - they are serialized on the
> mutex. Threads effectively take turns to make these calls.
>
>
>  my main doubt is: same sqlite3* is passing to 4 threads from the primary
>> thread.
>>
>> Is it correct way to implement multiple readers and single writer?
>>
>
> There are no technical problems with this, if that's what you are asking.
> It would work. But since all the work is serialized, a single thread that
> does all the reading and writing would be just as fast, if not slightly
> faster. You are adding complexity but are not gaining any performance out
> of it.
>
> --
> Igor Tandetnik
>
> __**_
> 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

Re: [sqlite] single gdbconn object with multiple threads.

[Igor Tandetnik]

On 7/23/2012 10:30 AM, Durga D wrote:

Unless your threads do something else in parallel, you could just as well

do all SQLite work on a single thread

doubt: all are parallel threads. started at same time. one thread is
writing and others are reading at the same time by using same sqlite3*.


Not really. What really happens is, one of the threads does some work, 
while the other three are sitting waiting on a mutex.



In this scenario, all are parallel.


Again - every SQLite API call acquires a mutex associated with the 
connection. If that mutex is already taken, then the thread sits there 
waiting for it to be released. In other words, two SQLite calls on the 
same connection never execute at the same time - they are serialized on 
the mutex. Threads effectively take turns to make these calls.



my main doubt is: same sqlite3* is passing to 4 threads from the primary
thread.

Is it correct way to implement multiple readers and single writer?


There are no technical problems with this, if that's what you are 
asking. It would work. But since all the work is serialized, a single 
thread that does all the reading and writing would be just as fast, if 
not slightly faster. You are adding complexity but are not gaining any 
performance out of it.

--
Igor Tandetnik

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] single gdbconn object with multiple threads.

[Simon Slavin]

On 23 Jul 2012, at 3:30pm, Durga D  wrote:

> my main doubt is: same sqlite3* is passing to 4 threads from the primary
> thread.

My understanding is that this does not happen.  There is no concept of 'server' 
and 'client' in the SQLite API, and it does no thread or process handling of 
its own.  If you make a function call in a particular thread of a particular 
process, the function runs in that thread.

A note based on your original post: the 'WAL' property of a database belongs 
with the database and is stored with the database.  You don't need to specify 
WAL mode each time you open the database, all connections with it will 
automatically know to use WAL mode until you use a PRAGMA command to change the 
mode again.  I know this doesn't help solve problem but it might help you 
understand what's going on.

I can't give you a definitive answer to your question but as far as I can see 
you're doing everything right, and should finish writing your program with 
those assumptions.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] single gdbconn object with multiple threads.

[Durga D]

Hi Igor,

Sorry.

>>Unless your threads do something else in parallel, you could just as well
do all SQLite work on a single thread

doubt: all are parallel threads. started at same time. one thread is
writing and others are reading at the same time by using same sqlite3*.

I passed same sqlite3* as an argument to 4 posix threads. Among 4, three
threads are reading (selct name from table where id < 10*index) from
database. Fourth thread is writer thread, which is inserting into database.

In this scenario, all are parallel. three threads are accessing database
for read and another one for write.

It's working fine in my sample application with WAL mode only.

my main doubt is: same sqlite3* is passing to 4 threads from the primary
thread.

Is it correct way to implement multiple readers and single writer?

please ignore intel tbb.

Regards,

On Mon, Jul 23, 2012 at 5:17 PM, Igor Tandetnik  wrote:

> Durga D  wrote:
> >   I have used same gdbconn for all the threads. In my sample application,
> > it working perfectly in wal mode.
> >
> >   Is it correct approach?
>
> Approach to what? You've never stated the problem you are trying to solve.
>
> With this setup, you don't get any concurrency out of your four threads.
> All SQLite API calls are serialized on one mutex associated with the
> connection. Unless your threads do something else in parallel, you could
> just as well do all SQLite work on a single thread.
>
> >   If yes, will tbb improves the performance for reader_threads?
>
> What's "tbb"?
> --
> Igor Tandetnik
>
> ___
> 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

Re: [sqlite] single gdbconn object with multiple threads.

[Igor Tandetnik]

Durga D  wrote:
>   I have used same gdbconn for all the threads. In my sample application,
> it working perfectly in wal mode.
> 
>   Is it correct approach?

Approach to what? You've never stated the problem you are trying to solve.

With this setup, you don't get any concurrency out of your four threads. All 
SQLite API calls are serialized on one mutex associated with the connection. 
Unless your threads do something else in parallel, you could just as well do 
all SQLite work on a single thread.

>   If yes, will tbb improves the performance for reader_threads?

What's "tbb"?
-- 
Igor Tandetnik

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] single gdbconn object with multiple threads.

[Durga D]

Hi all,

I developed sample application with below logic:

   1. in main(), got the valide gdbconn (type sqlite3*) after sqlite3_open
and sqlite3_prepare_v2.

   2. wal mode.

   3. created 4 threads and passed gdbconn as a argument to threads.

   4. Three are reader_threads. each reader thread executed different
queries. It's given correct results.

   5. Fourth thread is writer_thread. ||y updating the with same database
by using gdbconn. This is also working fine.


   I have used same gdbconn for all the threads. In my sample application,
it working perfectly in wal mode.

   Is it correct approach?


   If yes, will tbb improves the performance for reader_threads?


  Thanks in advance.

Regards,
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users