.NET中的时间关键过程 [英] Time Critical Process in .NET

问题描述

大家好


我有一个时间关键的过程，在一个工作线程上运行。通过时间

critical，我的意思是该过程的某些部分必须在

特定时间范围内完成。这个过程开始的时间并不是特别重要，但必须在几秒钟内完成。


我正在执行的操作不会需要很长时间（数百美元），但是随着流程的每个部分都完成，我的工作线程

会引发一个由UI线程处理的事件，使用已完成操作的详细信息更新富文本

控件。我正在使用一个富文本框

，这样当发生故障时我可以将信息涂成红色。


我遇到的问题是有时候，因为没有显而易见的原因，我的

过程中的一个步骤花费了过多的时间，例如2.5秒而不是

或许300毫秒。当发生这种情况时，整个过程超出了我的时间

帧，并且必须重复。当我重复这个过程时，它会在一个现实的时间内完成每一次

的机会，一切都很顺利。如果我停止输出到屏幕上的
，我不会遇到问题。


当更新UI线程上的屏幕时，我使用BeginInvoke来编组对正确的线程执行

操作，以免阻碍工作线程，

但这似乎没有帮助。


我意识到Windows（在这种情况下是XP）并不是这种类型的理想o / s
的应用程序，但有没有人对我如何制作我的

申请更具确定性？我不确定这些

2.5秒内发生了什么，所以如果我能找到它可能会有用，但我不确定

我怎么做。


TIA


Charles

Hi guys

I have a time critical process, running on a worker thread. By "time
critical", I mean that certain parts of the process must be completed in a
specific time frame. The time when the process starts is not especially
important, but it must be complete within a small number of seconds.

The operations I am performing do not take a long time (hundreds of
milliseconds), but as each part of the process is complete, my worker thread
raises an event that is handled by the UI thread, to update a rich text
control with details of the completed operation. I am using a rich text box
so that when a failure occurs I can colour the message red.

The problem I have is that sometimes, for no apparent reason, a step in my
process takes an inordinate amount of time, e.g 2.5 seconds instead of
perhaps 300 ms. When this happens, the complete process overruns my time
frame, and it has to be repeated. When I repeat the process there is every
chance that it completes in a realistic time, and all is well. If I stop
outputting to the screen, I do not get the problem.

When updating the screen on the UI thread, I use BeginInvoke, to marshal the
operation to the correct thread, and so as not to hold up the worker thread,
but this does not seem to help.

I realise that Windows (XP in this case) is not the ideal o/s for this type
of application, but does anyone have any ideas about how I could make my
application more deterministic? I am not certain what is going on in these
2.5 seconds, so it might be useful if I could find out, but I am not sure
how I would do that.

TIA

Charles

推荐答案

Charles，


你得到我几乎标准的答案（不过多一点，所以不要直接停止读书）。

当一个线程依赖于另一个线程而不是你不能使用

多线程（或者你应该使用乐观的多处理而不是我们

来自另一个完整的区域）。


但是当你能够将dependend过程带到

workerthread时，比你在这种情况下再次完成了。


Cor

Charles,

You get my almost standard answer (however a little bit more, so don''t
direct stop reading).

When one thread depends from another thread than you can not use
multithreading (Or you should use optimistic multiprocessing however than we
come in a complete other area).

However when you are able to bring the dependend process to the
workerthread, than you have fulfiled again on this condition.

Cor

您好Cor


我以为我是通过使用BeginInvoke删除依赖项。


我需要在一个单独的威胁上执行关键过程d，以便

用户界面保持响应，当然我无法更新

工作线程中的屏幕。


我想知道是否有办法制作我的过程中必不可少的部分

不可中断，所以我知道它们将一直执行，

没有被脱离背景。另外，有没有办法阻止

GC在关键时刻做这件事，因为我担心这也可能导致

任意延迟？


Charles

" Cor Ligthert" <无************ @ planet.nl>在消息中写道

news：uC ************** @ TK2MSFTNGP15.phx.gbl ...

Hi Cor

I thought that I was removing the dependency by using BeginInvoke.

I need the critical process to be performed on a separate thread so that the
UI remains responsive, and of course I cannot update the screen on the
worker thread for the usual reason.

I was wondering if there was a way of making essential parts of my process
not interruptible, so that I know that they will always execute in one go,
without being switched out of context. Also, is there a way of stopping the
GC from doing its thing at key times, as I fear this may also be causing
arbitrary delays?

Charles
"Cor Ligthert" <no************@planet.nl> wrote in message
news:uC**************@TK2MSFTNGP15.phx.gbl...

Charles，
你得到我几乎标准的答案（不过多一点，所以不要直接停止阅读）。

当一个线程依赖于另一个线程而不是你能不使用
多线程（或者你应该使用乐观的多处理，而不是
我们进入一个完整的其他领域）。

然而，当你能够将dependend进程带到<在这种情况下，你已经再次完成了。

Cor

Charles,

You get my almost standard answer (however a little bit more, so don''t
direct stop reading).

When one thread depends from another thread than you can not use
multithreading (Or you should use optimistic multiprocessing however than
we come in a complete other area).

However when you are able to bring the dependend process to the
workerthread, than you have fulfiled again on this condition.

Cor

" Cor Ligthert" <无************ @ planet.nl>写在

新闻：uC ************** @ TK2MSFTNGP15.phx.gbl ...

"Cor Ligthert" <no************@planet.nl> wrote in
news:uC**************@TK2MSFTNGP15.phx.gbl...

Charles，

你得到我几乎标准的答案（但是多一点，所以不要直接停止阅读）。

当一个线程依赖于另一个线程而不是你不能使用
多线程（或者你应该使用乐观的多处理，而不是
我们进入一个完整的其他领域。）

Charles,

You get my almost standard answer (however a little bit more, so don''t
direct stop reading).

When one thread depends from another thread than you can not use
multithreading (Or you should use optimistic multiprocessing however than
we come in a complete other area).

不！在后台线程中进行冗长的计算并显示

导致GUI线程是一种绝对常见的多线程情况。

我能想到的任何严重的多线程任务都涉及到某种形式

线程间通信/同步。


到OP：你永远无法保证你的上限

执行时间，但这主要是由于HD交换，有缺陷的驱动程序或

非合作实时进程。如果没有这种情况发生，那么你最好的选择

就是要找出*发生了什么。 （但你已经知道了。）


如果没有关于你的

应用程序的更多详细信息，很难给你更好的建议，但我'' d尝试以下方法：

- 打印当前时间（使用一些高分辨率计时器）在一些战略性的

点，以确切地找出*什么*需要那些2.5秒。在后台线程操作中，它总是一样吗？它是线程之间的通信吗？

- 监视.NET性能计数器。是否可能与GC收集或其他一些运行时事件有一些相关性？

- 您使用哪种GC？

- 2.5 s是相当的很久，也许你可以在调试器中中断你的过程

它发生了什么？

- 你能删除/简化部分应用程序（比如使用一些假的

计算而不是真实的，或使用简单的文本框），看看问题是否仍然发生？


希望其中一个这些有帮助...


Niki

No!!! Doing lengthy calculations in a background thread and displaying the
results in a GUI thread is an absolutely common multithreading situation.
Almost any serious multithreading task I can think of involves some kind of
inter-thread communication/synchronization.

To the OP: You''ll never be able to guarantee an upper limit of your
execution time, but that''s mainly due to HD swapping, buggy drivers or
non-cooperative realtime processes. If none of that happens, your best bet
is to find out *what* happens. (But you already knew that).

It''s hard to give you any better advices without more details about your
app, but I''d try the following:
- Print out the current time (using some high-res-timer) at some strategic
points to find out exactly *what* takes those 2.5 sec. Is it always the same
step in your background-thread operation? Is it the communication between
the threads?
- Monitor the .NET performance counters. Is there maybe some correlation to
GC collection or some other runtime event?
- Which GC do you use?
- 2.5 s is quite long, maybe you can interrupt your process in a debugger
while it happens?
- Can you remove/simplify parts of your application (like using some fake
calculation instead of the real one, or using a simple text box), to see if
the problem still happens?

Hope one of these helps...

Niki

这篇关于.NET中的时间关键过程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！