从单独的线程.NET连续监视和报告 [英] Continuous Monitoring and reporting from a separate thread .NET

问题描述

我正在编写一个应用程序 - 我想将一组参数传递给一个方法并在调用它之后异步和连续地运行该方法，当它正在运行时我希望它看到的值返回到调用例程而我希望能够连续[通过一个事件很好。]所以当监控线程感知到它将引发的变化时，我的调用应用程序/方法将处理该事件。异步方法将继续在后台运行。所以我想要一些帮助，如何做到这一点，最佳实践指南，.NET 4或4.5很好 - 首选是dot net 4.0。非常感谢任何帮助指南，尤其是示例。非常感谢大家的时间和精力。

I am writing an application - I want to pass a set of parameters to a method and run that method Asynchronously and Continually after calling it, While it is running I want the values it sees to be returned to the calling routine and I want to be able to do that continuously [via an event is fine.] So when the monitoring thread senses a change it will raise and event - my calling application / method will process the event. The Asynchronous method would continue to run in the background. So I would like some help with how to do this , best practice guidelines , .NET 4 or 4.5 is fine - the preference is dot net 4.0 . Any help guidelines and especially examples are very much appreciated. Thank you all so much in advance for your time and effort ..

推荐答案

同时没有绝对连续和异步的东西。当您想要监视一个线程时，您应该同步您的调用线程和另一个线程。最小的同步工具可以是一个锁： http://msdn.microsoft.com/en-us/library /c5kehkcz.aspx [ ^ ]。



这意味着线程有时会等待一点，这已经是不连续的了。



现在，如果你想要拉取处理（监控是由调用线程主动完成的，而不是正在监控的线程），这个解决方案本质上是无效的。这一点非常重要：

http://en.wikipedia.org/wiki/Pull_technology [ ^ ]，

< a href =http://en.wikipedia.org/wiki/Push_technology> http://en.wikipedia.org/wiki/Push_technology [ ^ ]。



推送技术要好得多。在您的情况下，它以下列方式实现：调用（监视）线程订阅要监视的线程。本质上，它将事件处理程序添加到与要监视的线程相关的代码的某个事件实例的调用列表中。然后，此线程仅在某些事物在其状态中发生实质性更改时才会调用此事件（或某些此类通知事件的集合）。对于这样的代码，拥有一个线程包装器很重要。请查看我过去的答案，其中显示了这样一个包含事件的包装：

C＃中的多线程 [ ^ ]。



另请参阅我对该主题的其他答案：

更改线程（生产者）启动后的参数 [ ^ ]，

如何将ref参数传递给主题 [ ^ ]。



上面引用锁的示例显示了拉取方法。锁是线程轮询所需的全部内容，但这不是一个好方法。如果您定期轮询它，则会浪费性能。如果你经常这样做，那么当没有真正发生的事情时，你会徒劳地做很多周期。在所有情况下，您都会错过某些事件，特别是在非频繁轮询的情况下，并且无论时间和优先级如何，都有可能错过它们。轮询，推送处理很糟糕。



你必须解决一个问题。监视线程应响应地处理事件。例如，如果它应该在UI中显示一些监视结果，则无法在调用事件的线程中执行此操作，因为它将是要监视的线程，而不是UI线程。因此，应该使用UI线程调用机制。这只是处理线程通知结果的一个示例。请查看我过去对此问题的回答：

控制.Invoke（）vs. Control.BeginInvoke（） [ ^ ]，

Treeview扫描仪和MD5的问题 [ ^ ]。

-SA

There is nothing absolutely continuous and asynchronous at the same time. When you want to monitor a thread, you should synchronize your calling thread and another thread. The minimal synchronization facility can be a lock: http://msdn.microsoft.com/en-us/library/c5kehkcz.aspx[^].

It would mean that threads sometimes wait for each other a bit, which is already non-continuous.

Now, if you want pull processing (monitoring is done periodically by the initiative of the calling thread, not a thread being monitoring), this solution is inherently ineffective. This is important thing to understand:
http://en.wikipedia.org/wiki/Pull_technology[^],
http://en.wikipedia.org/wiki/Push_technology[^].

Push technology is much better. In your case, it is implemented in the following way: a calling (monitoring) thread is subscribed to the thread to be monitored. Essentially, it adds an event handler to an invocation list of some event instance of the code related to the thread to be monitored. Then this thread invokes this event (or some of the set of such notification events), only when something is essentially changed in its state. For such code, it's important to have a thread wrapper. Please see my past answer showing such a wrapper with an events:
MultiThreading in C#[^].

See also my other answers on the topic:
Change parameters of thread (producer) after it is started[^],
How to pass ref parameter to the thread[^].

The example with the lock referenced above shows the pull approach. The lock is all you need for thread polling, but this is not a good way. If you poll it periodically, you waste performance. If you do it frequently, you do a lot of cycles in vain, when nothing really happens. In all cases, you miss some events, especially with non-frequent polling, and have some probability to miss them regardless of timing and priorities. Polling, push processing is bad.

There is one problem you have to address. The monitoring thread should responsively handle the events. For example, if it should show some monitoring results in UI, you cannot do it in the thread invoking the event, because it would be a thread to be monitored, not a UI thread. Hence, a UI thread invocation mechanism should be used. This is just one example of handling thread notification results. Please see my past answers on the problem:
Control.Invoke() vs. Control.BeginInvoke()[^],
Problem with Treeview Scanner And MD5[^].

—SA

在一个类中封装参数，例程和事件。

您的主应用程序创建它的实例，订阅事件，然后启动例程

Thread thread = new Thread（（）=> myObject.StartRoutine（））; thread.Start（）;

请注意，事件是在与UI线程不同的线程中触发的，因此如果需要在此处更新GUI，则必须调用Invoke。

Encapsulate the parameters, the routine, and the event in a class.
Your main application creates an instance of it, subscribes the event, then starts the routine
Thread thread = new Thread(() => myObject.StartRoutine()); thread.Start();
Note that the event is fired in a different thread than the UI thread, hence you will have to call Invoke if you need to update the GUI here.

大家好 - 在看到谢尔盖和伯纳德的答案之后 - 我决定使用提供的指导进行更多的搜索;感谢Bernhard简单地说，感谢谢尔盖谢谢你的记忆清单。我发现这篇文章对我来说非常优秀，我在这里找到：异步方法调用 [< a href =http://www.codeproject.com/Articles/14931/Asynchronous-Method-Invocationtarget =_ blanktitle =New Window> ^ ]

Hi All - after seeing Sergey and Bernhards answers - I decided to do a bit more searching using the guidance provided; Thank you Bernhard for stating simply , Thank you Sergey for your list of gotchas and things to remember. The article which I found and is most excellent for me I found here: Asynchronous Method Invocation[^]

这篇关于从单独的线程.NET连续监视和报告的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！