The issue here (with the INC instruction) isn't 'Thread' but "Multi-Master/(Core)' On as single processor, the INC is atomic. When you have a possibility of multiple masters (or cores) access the same location, you need to be more careful, and that LOCK prefix due to what it needs to do to caches is expensive. The more general application is that when you share information between concurrent operations you must be careful and use the right tools to make sure it 'works', and you don't want to use these all the time for things that aren't shared because they can get too expensive.
When dealing with an API, some items are designed to be used across threads, and some only within a single thread. You can sometimes get a single threaded API to work multithreaded by adding external synchronization (which can be clumsy), and you can use the multithreaded parts of the API in just a single thread, but they may be slower than a single threaded version of the API. The key is you need to read the documentation and follow the rules. -----Original Message----- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Simon Slavin Sent: Friday, February 17, 2017 6:48 AM To: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> Subject: Re: [sqlite] Thread safety of serialized mode On 17 Feb 2017, at 9:27am, Clemens Ladisch <clem...@ladisch.de> wrote: > X86(-64) has always had "INC [mem]" and "LOCK INC [mem]". It is insane that a CPU would allow two threads to interfere with each-other in such a way as to 'break' an INC instruction. But yes, we have drifted a long way from SQLite. Shuttup Simon. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
