> On Feb 17, 2017, at 3:48 AM, Simon Slavin <slav...@bigfraud.org> wrote: > > 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.
It may be insane to you, but it’s simply how multiprocessor computer architectures work, and railing against it won’t accomplish anything. Any multiprocessor/multicore computer is a distributed system — you can think of it as client/server where the clients are the CPUs and the RAM is the server. An INC instruction is a read / modify / write sequence. If you want this to be atomic, you have to use a transaction. Transactions are expensive. If every read/modify/write used a transaction, it would slow the system to a crawl, and 99.999% of the time it’s unnecessary. So the CPU makes it optional. In the case of the x86 INC instruction (which I didn’t know about), there is a LOCK flag that can be used to do this. A C compiler isn’t normally going to generate code that uses this flag, _unless_ you call an atomic-increment primitive. This has nothing to do with threads or programming languages. It’s simply the way today’s computer architectures work. There have been different multiprocessor architectures that didn’t share memory, but they never became practical enough to make it into general-purpose computers. (Actually one of them did: the GPU. But we don’t write database engines that run on GPUs, to my knowledge.) —Jens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
