Igor Tandetnik wrote:
> 
> pierr wrote:
>> Hi,
>>   My sqlite is configure as serialized (THREADSAFE=1). My application
>> has only one connection but it is shared by two thread. One thread
>> will do insert/update/delete in the background , another thread will
>> do the select upon request of the user from gui.
>>  Typically, we will call following function 12 times (with different
>> parameters ,of course)before showing the pages to user. In the
>> standalone test (single  thread), a call to following function will
>> take less than 40ms, so 12 times will take less than 500 ms and it is
>> acceptable. However, in the real application, sometimes this function
>> took 1000ms to return the result which make the gui slow.
> 
> When the second thread makes SQLite calls, it takes a lock on the 
> connection. If the UI thread runs a SELECT at this moment, it also tries 
> to take that lock, and so has to wait until the second thread releases 
> it.
> 
1. I expected the second thread would impact the SELECT thread but not that
much. The serach time increase as much as 6 times on average. But in my
experiment, when i add a usleep(10000) (10ms) in the INSERT thread, the
search time will back to normal.I am not sure if this is the POINT. I would
try this in my real application to see what happened.

2. I also suspect the increase of search time is caused by the SELECT thread
can not be scheduled timely to run because of INTERRUPT that happend very
frequently in my system , or because of other threads cost to much CPU time
like the other_thead in my expriment ,which has nothing but while(1).
(Actually ,I don't quite understand why this would impact the SELECT thread
(that much). Although other_thread has a while(1), I thought kernel (linux
2.6) should use time_sharing scheduler policy as both other_thread and
select_thread are nomal thread , i.e, not real time thread and no priority
set explicitly. So priority base preemptive should not be applied here. Any
idea? )

3.I think the way I use the sqlite (one thread for write , another for read)
is not uncommon. Do we have any best practice for the question I am asking
here?


Igor Tandetnik wrote:
> 
> Further, you cannot open two connections to the same in-memory database.
> 

This would be the thing that prevent me from going THREADSAFE=2.

-- 
View this message in context: 
http://www.nabble.com/search-time-is-non-determinate-in-multi-thread-enviroment-tp24693604p24711093.html
Sent from the SQLite mailing list archive at Nabble.com.

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

Reply via email to