动态使用计时器对象c#/.net

发布于 2024-12-02 12:23:24 字数 434 浏览 0 评论 0原文

我想看看是否有人有动态使用计时器的经验或技巧。我们需要一个 Windows 服务来定期检查文本文件。该文本文件将包含市场名称和开始时间。然后，该服务需要创建一个计时器来执行倒计时，并将倒计时信息写入 xml 文件...例如 23 分钟，

所有这些现在都可以在 Windows 应用程序上运行，用于一个计时器和一个倒计时...我们现在想要制作这个动态...

所以当服务启动时，它将为每个市场/倒计时创建一个计时器...（例如凤凰城上午 10 点，芝加哥晚上 11:45 等）。

然后该服务将检查该文本文件中是否有任何新条目...因此，如果该文件包含凤凰城、芝加哥，然后添加了纽约，我们希望该服务保持凤凰城和芝加哥计时器运行，然后为新条目启动计时器约克。

我只是不确定在一个服务下运行的多个计时器如何交互，以及当它们都需要写入同一个 xml 文件时线程如何工作。

对此有何想法？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

浅沫记忆 2024-12-09 12:23:24

我只是不确定在一个服务下运行的多个计时器如何交互，以及当它们都需要写入同一个 xml 文件时线程如何工作。
对此有什么想法吗？

效果不会很好。

计时器在线程池中排队。线程池一次只会创建一定数量的活动线程：

http://msdn.microsoft.com/en-us/library/0ka9477y.aspx" rel="nofollow">http:// /msdn.microsoft.com/en-us/library/0ka9477y.aspx

可以排队到线程池的操作数量仅受可用内存的限制；但是，线程池限制了进程中可以同时活动的线程数量

此外，从多个线程写入同一个文件将会产生不好的结果。

更不用说，如果所有这些线程都在运行，那么弄清楚应用程序正在做什么将会更加困难。

更简单的方法

采用现有的计时器并在其上构建您自己的不使用线程的计时系统。

创建一个定义倒计时条目的结构。

代码：

public class Countdown
{
    public DateTime Time { get; set; }
    public event Action Elapsed { get; set; }

    public void RaiseElasped()
    {
        if(Elapsed != null)
            Elapsed();
    }
}

读取您的文件，并创建：字典<字符串，倒计时>（名称 -> 倒计时）。在每个操作中放入与要放入计时器中的相同代码。
创建一个FileSystemWatcher来查找输入文件的更改。触发文件时，根据需要修改字典。
创建分辨率为一分钟的单个计时器。
每次触发计时器时，都会检查字典中的每个项目。如果目标时间已过，则调用 RaiseElapsed。（也可能将其从字典中删除？）

从这一点来看，很难准确确定您想要做什么，因为您没有描述写入文件的内容、发生的时间、发生的频率或倒计时结束后会发生什么。不过，您应该能够自己弄清楚其余的事情。

这种方法的优点是单线程程序更容易调试，并且您不会遇到您所询问的任何问题（并发文件访问或运行太多线程）。

缺点是当你有很多条目时，它可能会陷入困境。但如果您有很多条目，您实际上应该使用数据库而不是文件。

im just not sure how multiple timers running under a service would interact and how the threading will work when they all need to write to the same xml file.
any thoughts on this?

It won't work well.

Timers are queued to the thread pool. The thread pool will only create a certain number of active threads at a time:

http://msdn.microsoft.com/en-us/library/0ka9477y.aspx

The number of operations that can be queued to the thread pool is limited only by available memory; however, the thread pool limits the number of threads that can be active in the process simultaneously

In addition, writing to the same file from multiple threads is going to give you bad results.

Not to mention it will be much harder to figure out what your application is doing if you have all those threads running.

A simpler approach

Take an existing timer and build your own timing system upon it that doesn't use threads.

Create a structure defining a countdown entry.

Code:

public class Countdown
{
    public DateTime Time { get; set; }
    public event Action Elapsed { get; set; }

    public void RaiseElasped()
    {
        if(Elapsed != null)
            Elapsed();
    }
}

Read your file, and create: Dictionary<string, Countdown> (name -> countdown). Put the same code in each action that you were going to put in the timers.
Create a FileSystemWatcher to look for changes to your input file. When the file is triggered, modify the dictionary as necessary.
Create a single timer with a resolution of one minute.
Every time that timer is triggered, check each item in the dictionary. If the target time has passed, call RaiseElapsed. (possibly remove it from the dictionary, too?)

From this point, it is hard to determine exactly what you'd want to do, because you didn't describe what gets written to a file, when it happens, how often, or what happens once your countdown has elapsed. You should be able to figure out the rest yourself, though.

The advantage of this approach is that single-threaded programs are much easier to debug, and you won't get any of the issues your question asked about (concurrent file access, or having too many threads running).

The disadvantage is that it might bog down when you have a lot of entries. But if you have a lot of entries, you should really be using a database instead of of files.

回复收藏 0 原文