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
