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