System.Timer总是有一个线程池线程回调。我怎样才能使高优先级也非线程池线程？ [英] System.Timer always has a callback on a Threadpool thread. How can I make it non-Threadpool thread with high priority?

问题描述

我如何在一个单独的线程池System.Timer回调，或在一个专门的线程？

How do I make System.Timer callback on a separate threadpool, or on a dedicated thread?

背景

我有一个轻量级的监视器使用System.Timer一个重要的应用程序并且无法弄清楚如何使回调不会在一个线程池，并在高优先级来操作。

I have a lightweight monitor for a critical application using a System.Timer and can't figure out how to make the callback not be in a ThreadPool, and to operate at a high priority.

这种情况的原因是：

• 如果关键的应用程序无响应，线程池就会发出取消标记，或Thread.Abort的，或Win32的中止（即不运行终结器），以挂线。

• If the critical app is non-responsive, the ThreadPool will send a cancellation token, or Thread.Abort, or Win32 Abort (that doesn't run a finalizer) to the hanging thread.

如果该应用程序是CPU密集型，那么我的监视线程应该在最高优先级运行至prevent拒绝服务，以我的显示器

If the app is CPU bound, then my monitoring thread should run at a Highest priority to prevent a denial of service to my monitor

线程池可由于过多的线程，或者 MaxThreads 过低

The threadpool may be exhausted due to too many threads, or a value of MaxThreads that is too low

这是不可能在一个线程中的线程池设置优先级（据我所知）

it's not possible to set a priority on a Thread that is in the threadpool (AFAIK)

因此​​，我认为它需要有一个计时器，它的回调在一个单独的线程，虽然我不知道如何来实现这一目标。

As a result I think its necessary to have a Timer and it's callback on a separate thread, though I don't know how to achieve this.

如果这是可能通过创建一个单独的AppDomain中，将CLR还是让我在不同的AppDomain发出命令给其他线程？

If this is possible by creating a separate AppDomain, will the CLR still allow me to issue commands to other threads in a different AppDomain?

推荐答案

我想你可以使用 Thread.sleep代码在专用线程做到这一点。那就是：

I suppose you could do this by using Thread.Sleep on a dedicated thread. That is:

void MonitorProc(object state)
{
    while (!ShutdownSignaled)
    {
        Thread.Sleep(MonitorFrequency);
        // Do monitor stuff here
    }
}

如果您设置线程以高优先级，很可能它会工作按要求。这不是一个很好的解决方案，但。

If you set that thread at high priority, it's likely that it'll work as desired. It's not a great solution, though.

不过，你仍然有问题，你的一个线程可能会崩溃，这将需要关闭整个应用程序 - 包括显示器

However, you still have the problem that one of your threads could crash, which would take down the entire application--including the monitor.

您可能会考虑显示器运行在高优先级，并发送命令到使用套接字或WCF或其他通信信道的主应用程序单独的应用程序。这样一来，这款显示器会无法如果主应用程序崩溃死亡。你可以$ C c中的主要应用$在启动时自动启动监视器，如果它已不存在。

You might consider making the monitor a separate application that runs at high priority and sends commands to the main application using sockets or WCF or some other communications channel. That way, the monitor won't die if the main application crashes. You could code the main application to start the monitor automatically at startup if it isn't already there.

我不知道，但是，它是多么容易，你列出的条件，实际上会发生。让我们在列表中向下。

I wonder, though, just how likely it is that the conditions you list will actually happen. Let's go down the list.

我不明白你的第一个点在这里，除非它说，该计划可能会崩溃。在这种情况下，那么你应该只写一个单独的显示器应用程序。

I don't understand your first point here, unless it's to say that the program could crash. In that case, then you should just write a separate monitor application.

如果该应用程序是CPU密集型，你的显示器的线程仍然会得到一个时间片，如果所有线程都处于相同的优先级。即使其它线程都处于较高的优先级，你的显示器仍然会得到一个时间片，然后现在。除非线程是实时的优先级。和你不想这样做

If the app is CPU bound, your monitor thread will still get a timeslice if all the threads are at the same priority. Even if the other threads are at a higher priority, your monitor will still get a timeslice now and then. Unless the threads are at RealTime priority. And you don't want to do that.

如果您运行的线程，那么就用你的程序的一个根本问题 - 那你应该找到你把它在生产之前的一个问题。

If you run out of threads, then there's a fundamental problem with your program--a problem that you probably should have found before you put it in production.

最可靠的方法来做到这一点的监测将是一个单独的应用程序。

The most reliable way to do this monitoring would be with a separate application.

这篇关于System.Timer总是有一个线程池线程回调。我怎样才能使高优先级也非线程池线程？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！