场景：我正在开发 LOB 应用程序，因为在 Silverlight 中，每次对服务的调用都是异步的，因此在服务器端处理请求时不会自动阻止 UI。
Silverlight 还支持线程，据我了解，如果您正在开发 LOB 应用程序线程在您需要执行一些 IO 操作时最有用，但由于我不使用 OOB 应用程序，因此无法访问客户端资源和所有服务器请求默认是异步的。
在上述场景中是否使用了线程，或者任何人都可以提供一些很好的例子，通过使用线程我们可以提高性能。
我尝试在这个主题上进行大量搜索，但我发现了一些简单的线程示例，很难从中理解真正的好处。
感谢您的帮助
【问题讨论】：
标签： silverlight silverlight-3.0 multithreading
Tomasz Janczuk 还告诉pointed out，如果 UI 线程相当繁忙，您甚至可以通过将异步 WCF 调用编组到单独的线程来显着提高性能。而且我应该注意到，UI 线程可能会非常忙于做一些你不会预料到会破坏周期的事情，比如计算投影等等，所以这可能值得为你的应用程序研究（和测量）。
也就是说，我在过去 20 年的大部分时间里一直在编写 LOB 应用程序，除了同步 IO 之外，我还没有发现很多在 LOB 应用程序中添加多个线程值得增加复杂性的场景。
编辑 2010 年 4 月 2 日：前几天我与 Tomasz Janczuk 和 WCF 团队的其他一些人共进午餐，他们为我澄清了一些关于 WCF 如何与 Silverlight 后台线程一起工作的问题。有两件事需要关注：发送数据和接收数据（例如，来自双工回调或异步调用完成）。当您发送数据时，调用将始终由实际进行调用的线程进行。因此，如果您有大量需要序列化的数据，则可以通过将传出调用编组到后台线程（例如，使用 ThreadPool.QueueUserWorkItem）来获得小的性能提升。但这不太可能大幅提升性能。
但是，当您通过双工回调或异步 xxxCompleted 方法接收数据时，始终在最初打开连接的线程上接收数据。这意味着如果您明确打开连接，它将在该线程上接收数据；但如果您隐式打开连接，它将在您建立第一个出站连接的线程上接收数据。如果您需要在每次回调时更新 UI，这不会有太大的不同，因为您只需将调用编组回 UI 线程。但是，如果有时您只需要存储数据以供将来参考或处理，则可以通过在单独的线程上打开连接来显着提高性能，这样您就可以接收和处理回调而无需等待 UI 线程.
希望这会有所帮助。想着趁着头脑还记忆犹新的时候把它写下来。
【讨论】：
与其他应用程序一样，Silverlight 具有相同的优势。如果您在客户端上进行长时间运行的计算并且不想占用 main/ui 线程，那么线程是一个明显的选择。
另外，我还没有研究过，但我想如果你运行的是多核机器，你可以通过将工作分成多个单独的线程来提高性能。
【讨论】：