What language is that? Probably wrapper for this language introduces
its own mutexes.


Pavel

On Thu, Mar 4, 2010 at 2:07 PM, Luke Evans <luk...@me.com> wrote:
> 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
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to