Thanks guys.
Well, I had played with turning off the shared cache, and have just done so
again.
What I'm actually seeing is serialisation (or at least some apparently quite
coarse-grained synchronisation).
Here's some logging output on my Mac. The start/finished messages are logged
by each thread, bracketing the query.
010-03-04 10:41:41.490 SQLiteTest[19641:5603] Starting query on thread
<NSThread: 0x103e1ea80>{name = (null), num = 6}
2010-03-04 10:41:41.490 SQLiteTest[19641:420b] Starting query on thread
<NSThread: 0x102e18c70>{name = (null), num = 2}
2010-03-04 10:41:41.490 SQLiteTest[19641:5403] Starting query on thread
<NSThread: 0x115001040>{name = (null), num = 4}
2010-03-04 10:41:41.490 SQLiteTest[19641:1b03] Starting query on thread
<NSThread: 0x103e1e610>{name = (null), num = 3}
2010-03-04 10:41:41.490 SQLiteTest[19641:5503] Starting query on thread
<NSThread: 0x103e1e720>{name = (null), num = 5}
2010-03-04 10:41:47.640 SQLiteTest[19641:5703] Starting query on thread
<NSThread: 0x102e1aae0>{name = (null), num = 7}
2010-03-04 10:41:52.524 SQLiteTest[19641:420b] Finished query on thread
<NSThread: 0x102e18c70>{name = (null), num = 2} in 10.97s
2010-03-04 10:41:52.524 SQLiteTest[19641:5403] Finished query on thread
<NSThread: 0x115001040>{name = (null), num = 4} in 10.97s
2010-03-04 10:41:52.532 SQLiteTest[19641:5503] Finished query on thread
<NSThread: 0x103e1e720>{name = (null), num = 5} in 10.98s
2010-03-04 10:41:52.534 SQLiteTest[19641:5603] Finished query on thread
<NSThread: 0x103e1ea80>{name = (null), num = 6} in 10.98s
2010-03-04 10:41:52.534 SQLiteTest[19641:1b03] Finished query on thread
<NSThread: 0x103e1e610>{name = (null), num = 3} in 10.98s
2010-03-04 10:41:53.088 SQLiteTest[19641:5703] Finished query on thread
<NSThread: 0x102e1aae0>{name = (null), num = 7} in 5.45s
2010-03-04 10:41:53.089 SQLiteTest[19641:a0f] Finished all queries in 11.60s
With the shared cache turned on, these threads (which are all doing the exact
same query in this test) behave in the same 'serial' way, but the total time is
more like 4.5s.
Is there any other config that could cause this kind of entanglement between
separate threads doing simple reads (albeit with aliases, sorting and
grouping), or is there anything in the database file that might induce this?
Thanks again.
-- Luke
> On 2010-03-04, at 10:24 AM, Pavel Ivanov wrote:
>> The process experiment seems to confirm that very fast independent parallel
>> queries can be made on the same database, but clearly I would like the same
>> behaviour using multiple threads (and probably connections) in the same
>> process. Is this possible with some specific configuration of SQLite?
>
> Do not use shared cache if you want completely independent connections
> in each thread. Otherwise each call to sqlite3_step() will block other
> threads trying to call sqlite3_step() on the same database. Without
> shared cache they will be completely independent and work as if they
> were executed in different processes (including amount of I/O involved
> and amount of memory consumed).
On 2010-03-04, at 10:26 AM, Dan Kennedy wrote:
>> The process experiment seems to confirm that very fast independent
>> parallel queries can be made on the same database, but clearly I
>> would like the same behaviour using multiple threads (and probably
>> connections) in the same process. Is this possible with some
>> specific configuration of SQLite?
>
> Maybe, if you disable shared-cache. Of course then you will
> use more memory, make more read() calls etc.
>
> Each shared-cache has associated with it a mutex. The mutex
> is held for the duration of each sqlite3_step() call on a
> statement handle that accesses that shared-cache.
>
> Dan.
>
> _______________________________________________
> 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
