我有一些 C# 类库，它们的设计没有考虑并发、多线程、锁等因素...
代码结构非常好，很容易扩展，但它可以从多线程中受益匪浅：它是一组科学/工程库，需要在非常非常短的时间内执行数十亿次计算（现在它们不需要从可用的核心中受益）。
我想将所有这些代码转换成一组多线程库，但我不知道从哪里开始，而且我以前没有任何经验。
我可以使用任何可用的帮助以及任何推荐/建议。
我的建议是不要这样做。您编写的代码不是要并行使用的，因此它不会工作，并且会以难以调试的方式失败。
相反，我建议您提前决定代码的哪一部分可以从并行性中受益最多，然后从头开始重写该代码以实现并行。您可以利用面前未修改的代码，也可以利用现有的自动化测试。
使用 .NET 4.0 任务并行库可能会使工作变得更容易，但它不会完全弥合非并行设计的代码与并行设计的代码之间的差距。
我强烈建议您研究 .NET 4 和 Task Parallel Library（也可通过 Rx Framework 在 .NET 3.5sp1 中使用）。
它使许多并发问题变得更加简单，特别是数据并行变得更加简单。由于您正在处理大多数科学/工程库中的大型数据集，因此数据并行性通常是最佳选择...
对于一些参考资料，尤其是关于数据并行性以及分解和解决问题的背景，您可能需要阅读我关于 .NET 4 中的并行性的博客系列。
如果您以前没有任何多线程经验，那么我建议您首先通过查看各种资源来了解基础知识：https://stackoverflow.com/questions/540242/book-or-resource-on- c-并发
使整个库多线程需要全新的架构方法。如果您只是四处走动并开始在代码中的任何地方放置锁，您最终会使代码变得非常麻烦，甚至可能无法实现任何性能提升。
最好的并发软件是无锁和无等待的......这在 C# (.NET) 中很难实现，因为大多数集合都不是无锁、无等待甚至线程安全的。关于“无锁数据结构”有各种讨论。很多人都参考了 Boyet 的文章（非常好），并且有些人一直在把任务并行库作为 .NET 并发的下一个目标，但 TPL 在线程方面确实没有给你太多 -安全收藏。 .NET 4.0 即将推出
Collections.Concurrent，这应该会有很大帮助。 不建议使整个库并发，因为它从一开始就没有考虑到并发性。您的下一个选择是检查您的库并确定它的哪些部分实际上适合多线程，然后您可以为它们选择最佳的并发解决方案并实现它。要记住的主要事情是，当您编写多线程代码时，并发性应该会导致程序吞吐量的增加。如果未实现增加的吞吐量（即您匹配或吞吐量小于顺序版本），那么您不应该在该代码中使用并发。