On Feb 15, 2017, at 5:03 AM, a...@zator.com wrote: > > I suppose someday, programming languages can do an analogous translation in > our limited but safe, sequential programs.
Not as long as we require side effects to achieve anything of practical value. Any form of I/O is a “side effect” by my definition, whether that’s disk, network, GUI, or what have you. Avoiding threads is good because the well known problems with global variables magnify a combinatorially when multiple threads can access them simultaneously — literally *simultaneously* on a modern multi-core processor! — in any pattern you can conceive, and more you probably haven’t even thought of. The problem is combinatoric on the number of instructions in the program and the number of threads, which gives you a really big number really fast. Humans aren’t good at thinking about all N billion execution paths through a given program. Synchronization — whether that’s mutexes or transactions or message passing or something else — helps, but it always eats into the speed advantage of raw threads, so there will continue to be a continuous pressure to reduce synchronization rather than add more automatically. Go look up “lock free data structures” if you want to see the kind of thing being done in this area. Computers can help with the combinatoric explosion, but I’m not seeing a whole lot of progress on this with real world programs. I want a tool like lint(1) that will detect synchronization errors statically, but for now, I think you have to rely on dynamic tools like Helgrind: http://valgrind.org/docs/manual/hg-manual.html The problem with dynamic error detection is that it can only catch errors in code paths that you can trigger while the tool watches. This is about more than just simple code coverage, it’s about *combinatoric* code path coverage. If you don’t test all possible interleavings of instructions among the threads and cores, you can still miss an error, even if the tool knows how to detect it. I have to believe static thread correctness analysis is at least possible in principle, because humans do manage to see threading problems just by staring at the code long enough. It might require strong AI to do it, but it’s got to be possible to at least do as well as an expert human. But, that just means this becomes yet another, “Won’t it be great when we have strong AI?” wish. A tool like Helgrind isn’t enough by itself. It’ll blithely ignore your lock-free data structure code, for example. It’ll also fail to flag logical errors in your SQLite code where you’re missing transactions, for another. It’s worth repeating: Concurrency is hard. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
