在阅读SQLite时，我在FAQ中偶然发现了这句话:"Threads are evil. Avoid them."
我非常尊重SQLite，所以我不能无视这一点。根据“避免使用它们”的政策，我开始考虑还能使用什么来并行化我的任务。例如，我当前正在使用的应用程序需要始终响应的用户界面，并且需要不时轮询多个网站(每个网站至少需要30秒的时间)。
因此，我打开了从该FAQ链接的PDF，从本质上看来，该论文建议了几种与线程一起使用的技术，例如屏障或事务性内存-而不是任何一种完全替代线程的技术。
鉴于这些技术没有完全放弃线程(除非我误解了论文的意思)，我可以看到两个选择:SQLite FAQ并不从字面上讲其含义，或者存在实际的方法实际上避免了使用线程。有吗
只是简要介绍一下Tasklet/协作调度-在小例子中看起来不错，但我想知道是否可以通过完全协作的方式并行处理大量UI繁重的应用程序。如果您成功完成了此操作或知道了此类示例，则可以肯定地将其视为有效答案!
最佳答案
注意:此答案不再准确反射(reflect)我对这个主题的看法。我不喜欢它过于戏剧化，有点讨厌的语气。而且，我不确定我对当时可证明正确的软件的追求是没有用的，就像我当时想的那样。我将这个答案保留下来，因为它已经被接受并投票通过，并将其编辑为我目前认为会破坏它的东西。
我终于开始阅读报纸了。我从哪里开始？
作者正在演唱一首古老的歌曲，歌曲的内容如下:“如果您无法证明程序正确无误，我们将注定要失败!”当大声尖叫并伴有过度调制的电吉他和快速的鼓声时，声音听起来最好。当计算机科学属于数学领域时，学术界就开始演唱这首歌。在这个世界上，如果您没有证据，那么您就什么也没有。即使第一个计算机科学系从数学系脱离后，他们仍会唱歌。他们今天正在唱歌，没有人在听。为什么？因为我们其他人都在忙于创建有用的东西，所以无法证明软件中的好东西是不正确的。
线程的存在使证明程序正确的难度变得更大，但是谁在乎呢？即使没有线程，也只能证明最简单的程序是正确的。在使用线程后，为什么不能证明我的平凡程序(甚至不能证明是正确的)是否更令人无法证明，我为什么还要担心呢？我不。
如果您不确定作者是否生活在学术的梦幻世界中，则可以确定这一点，因为他坚持认为，他建议的替代线程的协调语言最好用“视觉语法”来表示(在图形上画出图形)。屏幕)。除职业生涯的每一年外，我从未听过这样的建议。只能由GUI操纵并且不能与程序员的任何常用工具一起使用的语言并不是一种改进。作者继续引用UML作为“常规与C++和Java结合”的可视化语法的出色示例。例行地在哪个世界？
同时，我和许多其他程序员继续使用线程而没有太多麻烦。只要您不完全依赖于可证明性，如何安全地良好地使用线程几乎是一个已解决的问题。
看。线程是一个大 child 的玩具，您确实需要了解一些理论和使用模式才能很好地使用它们。就像数据库，分布式处理或程序员每天成功使用的任何其他校外设备一样。但是，仅仅因为您无法证明它是正确的，并不意味着它是错误的。