On 1/4/18 8:02 PM, Jens Alfke wrote:
On Jan 4, 2018, at 4:51 PM, Ron Barnes <[email protected]> wrote:
I hope not since I use synclock in my code when ever a thread is attempting a
write to the database. That seems like the only issue from that page that I
may be doing. I could have up to 30 or more threads reading from the DB but
only one to three active threads writing.
It depends on the value of SQLITE_THREADSAFE that SQLite was compiled with.
(Check the docs for details.) If it’s set to 1, you can do what you’re doing.
Otherwise, you cannot use a single SQLite connection on multiple threads
without using your own mutex (if it’s 2), or at all (if it’s 0).
30 threads sounds like overkill, BTW. Generally the appropriate number is equal
to the number of CPU cores. And if the task is I/O-bound there’s not much
benefit to having more than one since only one of them can be inside SQLite at
a time.
—Jens
Limiting to number of CPU cores make sense for homogeneous threads
(multiple threads doing the same sort of work, so make it go in
parallel). One case where more can make sense is if they are
heterogeneous, each thread doing some unique task to keep the worker
threads simple.
--
Richard Damon
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
