On Thu, 16 Feb 2017 19:35:51 -0800 Jens Alfke <j...@mooseyard.com> wrote:
> > On Feb 16, 2017, at 6:26 PM, James K. Lowden > > <jklow...@schemamania.org> wrote: > > > > It doesn't change the fact that the OS has subverted the > > guarantees your language would otherwise provide, such as the > > atomicity of ++i noted elsewhere in this thread. > > It?s not the OS, it?s the architecture of multiprocessor systems. It's the OS. A thread is an OS abstraction, not a machine feature. You accept that exec(2) creates a single-threaded process that allows a language like C to express sequential logic. You accept that Posix threads provide a different flow of control. You know that to execute threads requires the OS to do some degree of context switching, and OS defines what a "context" is by what it chooses to preserve. You know you have can have many threads on a single processor. You know the OS determines things like thread affinity. A process and a thread, as defined by the operating system, are both OS abstractions, a representation of a machine. The OS *chooses* not to arbitrate access to memory, and the compiler *chooses* to expose the programmer to those pathological interactions. That's by design. Without the OS supporting threads, the machine's intrinsic multiprocessing implementation would not be exposed to the programmer, any more than are the intricacies of SATA or Ethernet chip design are. --jkl _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
