On Tue, 14 Feb 2017 17:05:30 -0800 Darren Duncan <dar...@darrenduncan.net> wrote:
> There is nothing inherently wrong with threads in principle What's inherently wrong with threads in principle is that there is no logic that describes them, and consequently no compiler to control that logic. By analogy, the Forth language has no datatypes. The programmer is free to treat any area of memory as encoded as any type; the only structure is the stack. Languages that do define datatypes allow the programmer to guarantee consistent treatment of variables by enforcing type constraints. Threads were and are a theoretical regression. They returned the programmer to the time when the programming environment provided no memory protection. They introduced a flow of control with no governance provided by the OS or the compiler. > Being multi-threaded is necessary to properly utilize the hardware, > or else we're just running on a single core and letting the others go > idle. The real problem is about properly managing memory. It's not necessary in general to give up protected memory to fully utilze the hardware. Rob Pike made some excellent presentations explaining the difference between parallel and concurrent operations, and how Go uses CSP to support concurrency. Go is a step in the right direction. By bringing threads under the control of the compiler, GoThreads give the programmer the efficiency threads afford without relinquishing control over memory. > Also giving sufficient hints to the programming language so that it > can implicitly parallelize operations. Afaik that's an unsolved problem. Take qsort(3) for example. I wrote a recursive version that runs in parallel. (Mine uses shared memory and fork(2)). What kind of a "hint" might the programmer provide to determine how many processes to use? Clearly, no static choice is right. Should qsort interrogate the machine and decide to use, say, 1/2 the processors? Why not all? But what if the machine is heavily loaded at the time qsort runs? Should it take the time to examine the machine state, and limit itself? Or should it just go ahead and let the OS deal with it? I decided on per-process regulation via an environment variable representing the approximate number of processes my qsort would spawn. If the variable is not set, the default is 2x the number of processors, which seems to the be upper limit for performance in my limited testing. So, yeah, threads are the 1990s version of 1960s computing. We seem to be on the cusp of recognizing the value of CSP to manage concurrency, and of functional programming to manage parallelism. That's far from the majority view, though, afaict. There's a lot more to be invented, and done. --jkl _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
