你从一个项目中学到了什么教训，这个项目由于多线程处理不好而几乎/实际上失败了？

Question

你从一个项目中学到了什么教训，这个项目由于多线程处理不好而几乎/实际上失败了？

有时，框架强加了一个特定的线程模型，这使得事情变得更加难以纠正。

至于我，我还没有从上次的失败中恢复过来，我觉得我最好不要在这个框架内做任何与多线程有关的事情。

我发现我擅长处理具有简单分叉/连接的多线程问题，而且数据只能向一个方向传输(而信号可以向圆形方向移动)。

我无法处理GUI，其中某些工作只能在严格序列化的线程(“主线程”)上完成，而其他工作只能在除主线程(“工作线程”)之外的任何线程上完成，而且数据和消息必须在N个组件(完全连通的图形)之间向各个方向移动。

当我离开这个项目去另一个项目的时候，到处都是死锁问题。我听说2-3个月后，其他几个开发人员设法解决了所有的死锁问题，以至于可以将其发送给客户。我从来没有找到我所缺少的知识。

有关该项目的内容:消息ID的数量(描述事件含义的整数值，无论线程如何，都可以发送到另一个对象的消息队列中)达到数千个。唯一的字符串(用户消息)也会运行到大约一千条。

添加了

我从另一个团队得到的最佳类比(与我过去或现在的项目无关)是“将数据放入数据库”。(“数据库”是指集中化和原子更新。)在一个被分割成多个视图的GUI中，所有运行在同一个“主线程”上的视图和所有非GUI的繁重工作都是在单个工作线程中完成的，应用程序的数据应该存储在一个像数据库一样的单一平台中，并让“数据库”处理所有涉及非琐碎数据依赖的“原子更新”。GUI的所有其他部分只是处理屏幕绘图，而不是其他任何东西。UI部件可以缓存内容，如果设计得当，用户不会注意到它是否过时了一秒。这个“数据库”在Document-View体系结构中也被称为“文档”。不幸的是-不，我的应用程序实际上将所有数据存储在视图中。我不知道为什么会这样。

同行贡献者：

(投稿人不需要使用真实的/个人的例子。从轶事中吸取的经验教训，如果你自己认为可信，也是值得欢迎的。)

Answer 1

我最喜欢的一课是:在多线程程序中，调度程序是一只讨厌你的狡猾的猪。如果事情可能出错，他们会的，但以一种意想不到的方式。如果做错了什么，你就会发现奇怪的heisenbugs (因为你添加的任何工具都会改变时间，给你一个不同的运行模式)。

解决这一问题的唯一正确方法是严格地将所有线程处理控制到一小块代码中，这样可以使其正常运行，并且在确保锁被正确持有方面非常保守(并且具有全局不变的获取顺序)。最简单的方法是在线程之间不共享内存(或其他资源)，除非消息传递必须是异步的；这可以让您以线程遗忘的方式编写其他所有内容。(好处是:扩展到集群中的多台计算机要容易得多。)

Answer 2

下面是我现在能想到的一些基本经验(不是来自失败的项目，而是来自实际项目中的实际问题)：

• 在保存共享资源时尽量避免任何阻塞调用。常见的死锁模式是线程抓取互斥，使回调，回调块在同一个互斥体上。
• 使用互斥/关键部分保护对任何共享数据结构的访问(或者使用无锁部分--但不要发明自己的！)
• 不要假设原子性--使用原子API(例如InterlockedIncrement)。
• RTFM有关您正在使用的库、对象或API的线程安全。
• 利用可用的同步基元，例如事件、信号量。(但在使用它们时，请密切注意，您知道自己的状态很好-我已经看到了许多事件在错误状态下发出信号的例子，以至于事件或数据可能丢失。)
• 假设线程可以同时执行和/或按任何顺序执行，并且该上下文可以在任何时候在线程之间切换(除非在提供其他保证的操作系统下)。

Answer 3

• 应该只从主线程调用整个GUI项目。基本上，您不应该在GUI中放置一个(.net)“调用”。多线程应该卡在处理较慢数据访问的单独项目中。

我们继承了GUI项目使用十几个线程的一个部分。它只会给你带来麻烦。死锁，赛车问题，跨线程GUI调用..。