> On Feb 16, 2017, at 11:49 AM, Warren Young <war...@etr-usa.com> wrote: > > A software developer who refuses to learn about his processor’s assembly > language is like trying to become an electrical engineer without learning > anything about physics.
In this case what you need to read is the specification of the memory model assumed by C and C++. The language specs are very explicit about what you can and can’t expect from concurrent memory accesses. (They’re also very hard to read! But fortunately there are good books about concurrent C/C++ programming that explain the rules clearly, like “C++ Concurrency In Action.) Of course that might not exactly match your CPU, because the specs are cross-platform and generally have to be very conservative … but in most cases it’s not a good idea to bake detailed knowledge of the CPU into your code, if you ever plan on porting that code to any other CPU. :) (Longtime programmers for Apple platforms know this especially well … I’ve been through transitions from the 68000 to the 68030, then to PowerPC, then to dual CPUs, then to 64-bit, then to X86, then to ARM7, then to ARM-64bit. Whew! Especially in the early stages, there were super clever things you could do that took advantages of details of the CPU architecture — like the way the 68000 ignored the high 8 bits of pointers — that then stopped working in the next generation and forced you to redesign your code.) —Jens PS: I’m not aware of _any_ current CPUs that can increment main memory in one instruction, atomically or not. The PDP-11 did famously have such an instruction, which is exactly why the ++ and -- operators were added to C’s parent BCPL, since it was intended as a “structured assembly language”. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
