> On Feb 17, 2017, at 9:18 AM, James K. Lowden <jklow...@schemamania.org> wrote: > > It's the OS. A thread is an OS abstraction, not a machine feature.
You don’t need an OS to create threads. All you need is setjmp/longjmp or the equivalent. “Green” threads are more awkward to use than kernel-supported threads, but they’re frequently used, and they can reproduce many of the nasty concurrency problems you get with “real" threads. > 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. OS arbitration of memory access at a fine-grained level is too expensive. Microkernel systems have made headway, but they still don’t match the performance of monolithic OS’s*, and I think that for the finer-grained concurrency that in-process threads are often used for, they’d be way too expensive. [from another email] > It's why I like Go: it's the first language in 30 years to incorporate > concurrency in its design, and finally support a theoretically sound > model. Goroutines are still threads, and Go programs can and do share memory between goroutines, which has all the same concurrency issues you find in C. Go has a Memory Model specification** that lays out the undefined results of unsynchronized access to memory by multiple goroutines, and it’s very much like what the C spec describes. I’ve used Go quite a bit in the past, but today I’m more interested in Rust and Pony which actually do prevent shared memory access in (supposedly) efficient ways. —Jens * https://en.wikipedia.org/wiki/Microkernel#Performance <https://en.wikipedia.org/wiki/Microkernel#Performance> ** https://golang.org/ref/mem _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
