多线程应用中的设计与技术问题

Question

我想讨论与多线程应用程序相关的设计和技术问题/挑战。

问题我面对的是

1.我遇到了这样的情况:多个线程正在使用共享函数/变量崩溃应用程序，因此需要适当的保护。

1. 状态机和多线程-

在深入研究多线程应用程序之前，应该记住几点。可以发出与1.内存2.处理3.套接字等相关的问题。

请在以下几点上分享你的经验

1. 多线程应用程序中常见的错误是什么？
2. 任何与多线程相关的特定问题。
3. 是通过值传递数据还是通过线程函数中的引用传递数据。

Answer 1

嗯，有那么多.

1)共享函数/过程--它们只是代码，除非代码自己修改，否则不会有问题。局部变量是没有问题的，因为每个线程都调用一个单独的堆栈(按定义为：)。任何其他数据都可能出现问题，可能需要保护。在multiTasking操作系统上的所有家庭API调用中，99.99%是线程安全的，这几乎是定义上的。另一张海报已经警告过线程本地存储.

2)国家机器。可能会有点尴尬。您可以轻松地锁定所有触发到SM中的事件，从而确保状态的完整性，但是在SM被锁定时，您不能从SM内部发出阻塞调用(可能看起来很明显，但我已经这样做了。)一次:)。

我偶尔只从一个线程运行状态机，将事件对象排队到它。这将锁定移至输入队列，并意味着SM更易于调试。这还意味着运行SM的线程可以在内部增量队列上实现超时，因此它本身就会触发对增量队列上的对象的超时调用(典型的示例:具有连接超时的TCP服务器套接字--每个都需要独立超时的数千个套接字对象)。

3)“是通过值传递数据还是通过线程函数中的引用传递数据。”不知道你是什么意思，给你。大多数操作系统允许线程创建时传递一个指针--随你怎么做。您可以向它传递一个它应该在工作完成时发出信号的事件，或者一个等待工作请求的队列对象。创建之后，您需要某种形式的线程间通信来发送请求并获得结果(除非要使用直接‘读/写/等待form’机制-AV/死锁/noClose生成器)。

我通常使用一个简单的信号量/CS生产者-消费者队列在工作线程之间发送/接收逗号对象，使用PostMessage API将它们发送到UI线程。除了队列中的锁定之外，我不需要更多的锁定。您必须非常努力地锁住一个基于消息传递的线程系统--并且线程池之类的东西变得微不足道--只需拒绝即可。对CPU线程进行处理，并将每个线程传递相同的队列等待。

常见的错误。请参阅其他许多海报，我还想补充如下：

( a)直接读写线程字段以传递参数和返回结果(尤指。在UI线程和'worker‘线程之间)，即’创建挂起的线程，将参数加载到线程字段，恢复线程，等待线程句柄退出，从线程字段读取结果，释放线程对象‘。这会导致持续创建/终止/销毁线程的性能受到影响，并且经常迫使开发人员在退出应用程序时确保线程被终止，以防止AV/216/217在关闭时出现异常。这可能是非常棘手的，在某些情况下是不可能的，因为一些API的块无法打开它们。如果开发人员停止这种讨厌的做法，应用程序关闭问题就会少得多。

( b)尝试以程序的方式构建multiThreaded应用程序，例如。尝试在UI事件处理程序中等待工作线程的结果。构建线程请求对象、使用参数加载线程、将其排队到工作线程并退出事件处理程序要安全得多。线程可以获取对象，完成工作，将结果放回对象中，并且(无论如何，在PostMessage上)返回对象。UI消息处理程序可以处理结果并处理对象(或循环、重用：)。这种方法意味着，由于UI和worker总是在不同的数据上操作，这些数据都可以超过它们，因此不需要锁定，也不需要(通常)确保在关闭应用程序时释放工作线程(这是分类帐中的问题)。

雷格斯·马丁

Answer 2

在多线程应用程序中，人们面临的最大问题是种族条件、死锁，而不是使用某种信号量来保护全局可访问的变量。

Answer 3

在使用线程锁时，您将面临这些问题。死锁优先级反转，使“异步信号安全”破坏容忍可用性抢占性的总体性能

如果您想了解更高级的线程处理技术，您可以查看无锁线程，其中许多线程在等待时处理相同的问题。