Indy是否在XP上使用某种协作多任务处理，如果是的话，是否有一种切换到其他连接的方法？
我有一个web服务器，它运行于Indy的TIdTCPServer组件上。我有几个请求同时传入，需要同步，所以每个请求在发送之前的请求后都会得到处理。这是用互斥完成的。在Vista和Win7上，这很好用，但在XP上，互斥服务器上的等待似乎也会挂起其他连接。它超时5秒后，所以它仍然会继续，但我的应用程序是非常时间敏感。
我想XP上的情况是这样的：
连接1：
- 解析请求
- 尝试获取互斥
- 成功
- 做些事情
- Reply -> Indy利用这个机会切换线程
连接2：
- 解析请求
- 尝试获取互斥
- 因超时而失败
- 返回“对不起，超时”-> Indy切换回连接1
连接1：
- 释放互斥
如果印第像这样使用合作的多任务处理，我将不得不做其他的事情。有没有人知道在XP上它是否使用协作多任务处理？
编辑：
所以，我在IdYarn中看到，纱线现在是一个完全空的物体。尽管如此，这个问题仍然存在于合作多任务处理方面。
回答 3
Stack Overflow用户
发布于 2011-12-02 05:00:44
TIdTCPServer中的每个连接都在自己的工作线程中运行。操作系统(而不是Indy )控制线程之间的任务切换。如果一个线程成功地锁定了互斥锁，那么在第一个线程解锁之前，其他线程都不能进入锁。在任何操作系统版本上，这都是多线程编程101。这种行为并不是印地特有的。你所描述的是它应该如何表现。如果Vista/Win7 7不是那样的话，那么您就有问题了。
Stack Overflow用户
发布于 2012-06-23 22:38:42
实际上，XP很可能是一个协作/先发制人的混合多任务程序。在一个真正的抢占式多任务处理器下，不能有一个控制处理器的进程，因为抢占式任务切换程序不允许它这样做。在协作多任务处理器下，您可以拥有一个可以控制处理器的进程，这将导致这样一个系统的崩溃。在XP中，我们的进程最多可支配处理器99 %的时间，但通常不是100 %的时间。这种行为清楚地表明XP是一个协作/抢占式多接受者。XP允许进程决定它将运行多长时间，然后将控制传递回系统，直到某个点。如果进程试图超越这一点，那么XP将使用它的先发制人能力来限制这一点。
Stack Overflow用户
发布于 2011-12-02 18:28:52
正如我在评论中提到的，Indy线程(TIdYarn)让操作系统执行调度(因为它们是OS线程)。
您所描述的场景仍然可以发生在先发制人的多任务处理中。使用锁互斥可以帮助解决问题，但这并不是整个解决方案。
首先，确保您的互斥锁是OnExecute中的第一件事。这将防止其他线程在处理队列前面的线程时占用处理器时间。
您说明您的应用程序是时间敏感的。如果这意味着您期望每个请求的响应时间较短，那么您需要执行FIFO (先入先出)，这是解决方案的第二部分。
你所描述的计划并没有解释这一点。如果线程A有互斥锁，同时线程B到Z出现等待锁，则线程B不能保证下一步获得锁。下一个锁可能是Z。事实上，B可以最后获得锁，并在此之前超时。
有一个相当大的Vista的几项改进使得同等优先级的线程之间的调度更加公平。如果您的线程以较低的优先级运行，则对Windows的影响将更加严重。也许这就是你所看到的，再加上你没有FIFO这个事实。
如果有很多线程在等待，并且没有FIFO实现，我希望在单个线程上超时。
https://stackoverflow.com/questions/8351528
复制相似问题
腾讯云开发者
