> On Feb 14, 2017, at 11:58 PM, Clemens Ladisch <clem...@ladisch.de> wrote: > > But "go parallel" does not necessarily imply threads. There are many > ways to allow code running on different CPUs(/cores) to communicate > with each other (e.g., files, sockets, message queues, pipes, shared > memory, etc.), and almost all of them are safer than threading because > they do not require that _all_ of the address space and the process > context are shared.
Yes, but they’re also _much_ more expensive, for pretty much the same reason. A process context switch requires updating the MMU and a bunch of kernel state. A thread switch just requires swapping CPU registers. (Depending on the OS there may be a system call involved, but that can be avoided by using ‘green’ threads, which are basically just a wrapper around setjmp/longjmp.) There are several orders of magnitude of difference in performance (though the details depend on the CPU and the OS.) > When using threads, all memory accesses are unsafe > by default, and it is then the job of the programmer to manually add > some form of locking to make it safe again. This depends on the language and/or the concurrency library. In a managed language it’s perfectly feasible to make it impossible for two threads to access the same memory (Rust and Pony do this.) In unmanaged code you can’t make strong guarantees, but you can get the same effect as long as the programmer doesn’t use unsafe techniques like global variables. I think we have a problem with terminology. The issue here isn’t threads themselves, but with how threads communicate. In most languages, the default is that you use shared memory and some locking primitives. _That’s_ the nasty evil part. Alternative concurrency mechanisms like channels and actors still use threads under the hood; they just give the programmer safer and more deterministic ways to communicate. —Jens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
