You never *need* to change SQLITE_CONFIG_MULTITHREAD. The default mode is "serialized", which means that if you "accidentally" violate the serial entrance requirements of a connection (by accessing it simultaneously on multiple threads) that all hell will not break loose. This is achieved by putting a mutex on the database connection to ensure that it is only being actively used in one thread at a time.
If you change the threading mode to MULTITHREADED nothing changes EXCEPT that the mutex to ensure that all hell does not break loose is not used. This may save "a wee bit" of processing time each time you enter the library since the mutex does not need to be obtained. Whether this is noticable by your application or not depends. For example, if you run queries that each take '2 million ticks', then the 2 tick savings (per call) are not noticeable. On the other hand, if you perform lots of '3 tick' calls into the library, then saving '2 ticks' on each call is significant. If you change the default threading mode to multithreaded and all hell breaks loose (but it does not break loose in the default serialized setting), then you are inadvertantly violating the rules. Like everything, it is a trade off, in this case between safety and performance. So, in theory you *may* dispense with serialized default and use the multithreaded mode -- that choice is up to you. But it is not (ever) required. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: sqlite-users [mailto:sqlite-users- >[email protected]] On Behalf Of Deon Brewis >Sent: Tuesday, 27 March, 2018 14:55 >To: SQLite mailing list >Subject: [sqlite] SQLITE_CONFIG_MULTITHREAD needed for connection >pool? > >The model we use for SQLITE is to use a connection pool (connections >opened via sqlite3_open_v2). > >We have many threads, but only one thread can use a connection at a >time - a thread takes it out of the pool, and when done, returns it >to the pool. > >The only exception to this is calls to: sqlite3_interrupt(), which >can be called from any thread. > > >Under that model, do we need to pass SQLITE_CONFIG_MULTITHREAD ? > >- Deon > >_______________________________________________ >sqlite-users mailing list >[email protected] >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
