Rom*_*kov 12 language-agnostic multithreading thread-safety
在阅读SQLite时,我在FAQ中偶然发现了这句话:"线程是邪恶的.避免使用它们."
我非常尊重SQLite,所以我不能忽视这一点.根据"避免他们"政策,我想到了我还能做什么,而是使用它来平行我的任务.例如,我目前正在处理的应用程序需要一个始终响应的用户界面,并且需要不时地轮询多个网站(每个网站至少需要30秒).
所以我打开了从常见问题解答链接的PDF,基本上似乎本文提出了几种与线程一起应用的技术,例如障碍或事务性内存 - 而不是任何完全替换线程的技术.
Given that these techniques do not fully dispense with threads (unless I misunderstood what the paper is saying), I can see two options: either the SQLite FAQ does not literally mean what it says, or there exist practical approaches that actually avoid the use of threads altogether. Are there any?
Just a quick note on tasklets/cooperative scheduling as an alternative - this looks great in small examples, but I wonder whether a large-ish UI-heavy application can be practically parallelized in a solely cooperative way. If you have done this successfully or know of such examples this certainly qualifies as a valid answer!
注意:此答案不再准确反映我对此主题的看法.我不喜欢它过于戏剧性,有点讨厌的语气.此外,我不太确定对可证明正确的软件的追求是如此无用,因为我似乎回想起来.我正在离开这个答案,因为它被接受,并被投票,并将其编辑成我目前认为会破坏它的东西.
我终于开始阅读这篇论文了.我从哪里开始？
作者正在唱一首老歌,如下所示:"如果你不能证明这个节目是正确的,我们都注定要失败!" 当伴随着调制电吉他和快速鼓声大声尖叫时,这听起来是最好的.当计算机科学处于数学领域时,学者们开始唱这首歌,如果你没有证据,你就什么都没有.即使在第一个计算机科学系被从数学系解剖之后,他们仍然在唱这首歌.他们今天正在唱这首歌,没有人在听.为什么？因为我们其他人正在忙于创造有用的东西,所以软件中的好东西无法证明是正确的.
线程的存在使得证明程序正确变得更加困难,但是谁在乎呢？即使没有线程,也只能证明最简单的程序是正确的.为什么我关心的是,在使用线程后,我的非平凡程序(无法证明是正确的)更难实现？我不.
如果你不确定作者是否生活在一个学术梦想世界中,你可以肯定的是,他坚持认为他建议作为线程的替代品的协调语言最好用"视觉语法"来表达(在屏幕).我以前从未听过这个建议,除了我职业生涯的每一年.只能通过GUI操作并且不能使用任何程序员常用工具的语言并不是一种改进.作者继续引用UML作为视觉语法的一个光辉的例子,它"通常与C++和Java结合".常规在什么世界？
与此同时,我和许多其他程序员继续使用线程而没有那么多麻烦.如何安全地使用线程几乎是一个解决的问题,只要你没有把所有问题挂起来.
看.线程是一个大孩子的玩具,你需要知道一些理论和使用模式才能很好地使用它们.就像数据库,分布式处理或程序员每天成功使用的任何其他超级学校设备一样.但仅仅因为你无法证明它是正确的并不意味着它是错的.
正如我所读到的,SQLite FAQ中的声明只是对未经授权的线程有多么困难的评论.这是作者的观点,它可能是有效的.但是,在我看来,说你永远不应该使用螺纹将婴儿扔出洗澡水.线程是一种工具.像所有工具一样,它们可以被使用,并且可以被滥用.我可以阅读他的论文,并确信线程是魔鬼,但我已成功使用它们,而不会杀死小猫.
请记住,SQLite的编写尽可能轻巧且易于理解(从编码的角度来看),因此我认为线程与这种轻量级方法的对立.
此外,SQLite并不适用于高度并发的环境.如果您有其中一个,那么最好使用像Postgres这样的企业级数据库.