线程 - 暂停，恢复，中止 [英] threading - suspend, resume, abort
问题描述
我有一个应用程序，它包含一个主要工作线程和
多个线程，每个线程都维护一个TCP套接字。
发生配置更改时，套接字线程上的所有活动
必须暂停。如果套接字不再在配置中，则必须中止该b / b $ b线程并且必须关闭套接字。在
配置完成后，必须恢复剩余的线程。
我目前有以下架构：
1）暂停所有线程
2）中止不再需要的线程并关闭其插座
3）恢复所有剩余线程。
如果我挂起一个线程然后中止它，CPU使用率会跳到100％。我必须先恢复该线程然后中止它。
必须先恢复该线程。这似乎没什么，所以我想知道我是否在这里遗漏了一些东西。
我也在MSDN中发现微软不建议使用这些
方法。如果是这样，那么适当的技术是什么？
谢谢，
基思
I have an application which consists of a main work thread and
multiple threads which each maintain a TCP socket.
When a configuration change occurs, all activity on the socket threads
must be halted. If a socket is no longer in the configuration, that
thread must be aborted and the socket must be closed. After the
configuration is complete, the remaining threads must be resumed.
I currently have the following architecture:
1) Suspend all threads
2) Abort threads which are no longer required and close their sockets
3) Resume all remaining threads.
If I suspend a thread and then abort it, CPU usage jumps to 100%. I
must first resume the thread and then abort it. This doesn''t seem
right, so I''m wondering if I''m missing something here.
I also found in MSDN that Microsoft does not recommend using these
methods. If that''s the case, then what is the proper technique?
thanks,
Keith
推荐答案
我会采用非常不同的方式：
而不是打断所有线程并粗暴地中止其中一些
配置更改，我会执行以下操作：
每个线程必须有某种循环，如
while（ReadRequest（））{
DispatchRequest（）;
WriteResponse（）;
}
（当然这是伪代码）。
在ReadRequest中，我会通过
调用查询配置管理器，如configManager.IsAllowed（connectionInfo），如果
$ b $则终止循环b该方法返回false。
如果配置发生变化，我会调用类似
configManager.ChangeConfig（configInfo）的方法。
然后，你只需要解决两个问题：
*确保您的配置管理器已正确同步。
方法IsAllowed和ChangeConfig应该在一个公共锁定上同步
这样一个线程不能调用IsAllowed而另一个线程在中间
执行ChangeConfig。
*在ReadRequest中使用异步读取而不是同步读取，这样你就可以终止不允许但被阻止的线程
等待输入。想法是调用StartRead，然后等待。在IAsyncResult的
ASyncWaitHandle上。在你的配置管理器中，你应该在所有需要终止的连接中设置一个标志
并发信号给他们
ASyncWaitHandle。这将允许您终止这些线程，而不必等待他们接收更多输入。
使用此策略，您不需要使用任何线程控制方法
（Abort，Suspend，Resume），你只使用同步原语（lock，
等）。这样更清洁，更有效。
另外，你应该避免暂停尽可能多的，除非你是
要恢复线程或之后立即中止。如果你
暂停一个帖子并且不能恢复它或者之后立即中止它，你
阻止它在未知点执行，你可以很好地阻止它在一段代码中，它获得了一些锁。这可能会阻止其他
线程（未被挂起）获取这些锁，并且您运行
获得一般死锁的风险（至少在线程恢复之前） ）。
因此，要非常小心暂停因为它会以危险的方式干扰
锁定/等待同步模式。
布鲁诺。
" Keith Langer < TA ****** @ aol.com> aécritdansle message de
news：15 ************************** @ posting.google.c om ...
I would do it very differently:
Instead of interrupting all the threads and aborting some of them brutally
when the config changes, I would do the following:
Every thread must have some kind of loop like
while (ReadRequest()) {
DispatchRequest();
WriteResponse();
}
(this is pseudo-code of course).
In the ReadRequest, I would interrogate the configuration manager, with a
call like configManager.IsAllowed(connectionInfo), and terminate the loop if
the method returns false.
If the configuration changes, I would call a method like
configManager.ChangeConfig(configInfo).
Then, you only have to solve two problems:
* Make sure that your configuration manager is correctly synchronized. The
methods IsAllowed and ChangeConfig should be synchronized on a common lock
so that a thread cannot call IsAllowed while another thread is in the middle
of executing ChangeConfig.
* Use asynchronous rather than synchronous read in ReadRequest, so that you
can terminate the threads that are not allowed any more but are blocked
waiting for input. The idea is to call StartRead and then "Wait" on the
ASyncWaitHandle of the IAsyncResult. In your config manager, you should set
a flag in all the connections that need to be terminated and signal their
ASyncWaitHandle. This will allow you to terminate these thread without
having to wait for them to receive more input.
With this strategy, you don''t need to use any of the thread control method
(Abort, Suspend, Resume), you only use synchronization primitives (lock,
wait). This is much cleaner and more efficient.
Also, you should avoid "Suspend" as much as possible, except if you are
going to resume the thread or abort it immediately afterwards. If you
Suspend a thread and don''t resume it or abort it immediately afterwards, you
block its execution at an unknown point, and you may very well block it in a
piece of code where it has acquired some locks. This may prevent other
threads (that are not suspended) to acquire these locks, and you run the
risk of getting a general deadlock (at least until the thread is resumed).
So, be very careful with "Suspend" because it interferes in dangerous ways
with the lock/wait synchronization pattern.
Bruno.
"Keith Langer" <ta******@aol.com> a écrit dans le message de
news:15**************************@posting.google.c om...
我有一个应用程序，它包含一个主要工作线程和多个线程，每个线程都维护一个TCP套接字。
当配置发生更改时，必须暂停套接字线程上的所有活动。如果套接字不再在配置中，则必须中止该线程并且必须关闭套接字。在
配置完成后，必须恢复其余的线程。
我目前有以下架构：
1）暂停所有线程
2 ）中止不再需要的线程并关闭它们的插槽
3）恢复所有剩余的线程。
如果我挂起一个线程然后中止它，CPU使用率会跳到100％。我必须首先恢复该线程然后中止它。这看起来不对，所以我想知道我在这里是否遗漏了什么。
我也在MSDN中发现微软不建议使用这些
方法。如果是这样，那么适当的技术是什么？
谢谢，
基思
I have an application which consists of a main work thread and
multiple threads which each maintain a TCP socket.
When a configuration change occurs, all activity on the socket threads
must be halted. If a socket is no longer in the configuration, that
thread must be aborted and the socket must be closed. After the
configuration is complete, the remaining threads must be resumed.
I currently have the following architecture:
1) Suspend all threads
2) Abort threads which are no longer required and close their sockets
3) Resume all remaining threads.
If I suspend a thread and then abort it, CPU usage jumps to 100%. I
must first resume the thread and then abort it. This doesn''t seem
right, so I''m wondering if I''m missing something here.
I also found in MSDN that Microsoft does not recommend using these
methods. If that''s the case, then what is the proper technique?
thanks,
Keith
基思Langer< ta ****** @ aol.com>写道：
Keith Langer <ta******@aol.com> wrote:
我有一个应用程序，它包含一个主要工作线程和多个线程，每个线程都维护一个TCP套接字。
当配置发生更改时，所有套接字线程上的活动必须暂停。如果套接字不再在配置中，则必须中止该线程并且必须关闭套接字。在
配置完成后，必须恢复其余的线程。
我目前有以下架构：
1）暂停所有线程
2 ）中止不再需要的线程并关闭它们的插槽
3）恢复所有剩余的线程。
如果我挂起一个线程然后中止它，CPU使用率会跳到100％。我必须首先恢复该线程然后中止它。这看起来不对，所以我想知道我在这里是否遗漏了什么。
我也在MSDN中发现微软不建议使用这些
方法。如果是这样，那么适当的技术是什么？
I have an application which consists of a main work thread and
multiple threads which each maintain a TCP socket.
When a configuration change occurs, all activity on the socket threads
must be halted. If a socket is no longer in the configuration, that
thread must be aborted and the socket must be closed. After the
configuration is complete, the remaining threads must be resumed.
I currently have the following architecture:
1) Suspend all threads
2) Abort threads which are no longer required and close their sockets
3) Resume all remaining threads.
If I suspend a thread and then abort it, CPU usage jumps to 100%. I
must first resume the thread and then abort it. This doesn''t seem
right, so I''m wondering if I''m missing something here.
I also found in MSDN that Microsoft does not recommend using these
methods. If that''s the case, then what is the proper technique?
每个套接字的工作线程应该定期检查它是否是
需要暂停/重启/关闭。通常这只是
改变无限循环条件的情况。
-
Jon Skeet - < ; sk *** @ pobox.com>
http：//www.pobox .com / ~siget
如果回复小组，请不要给我发邮件
Each socket''s work thread should regularly check whether or not it
needs to pause/restart/shutdown. Usually this is just a case of
changing the condition of an otherwise endless loop.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
谢谢大家。我采取了从主线程
设置标志的方法，它指示套接字线程中止或挂起。现在插座
线程在安全的情况下处理这些操作。
根据MSDN，Abort方法只在安全时执行，所以
我猜它至少等到所有的锁都被释放了。这不是这种情况吗？在测试之后，我发现
中止确实需要几秒钟。
还有一个问题 - 如果主线程可以读取或写入哈希表
并且套接字线程从该哈希表中读取，当套接字线程正在访问
项时，是否存在任何写入操作不完整的危险？靠它的钥匙？我没有使用枚举。
谢谢，
基思
***通过Developersdex http://www.developersdex.com ***
Don''只是参加USENET ......获得奖励！
Thanks guys. I took the approach of setting a flag from the main thread
which directs the socket thread to abort or suspend. Now the socket
thread handles these actions when it is safe to do so.
According to MSDN, the Abort method only executes when it is safe, so
I''m guessing that at the very least it waits until all locks are
released. Is this not the case? After testing it, I found that the
abort did take a few seconds.
One more question - if the main thread can read or write to a hashtable
and the socket thread reads from that hashtable, is there any danger of
an incomplete write operation while the socket thread is accessing an
item by its key? I am not using enumeration.
thanks,
Keith
*** Sent via Developersdex http://www.developersdex.com ***
Don''t just participate in USENET...get rewarded for it!
这篇关于线程 - 暂停，恢复，中止的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
