How to do different things synchronous using timer by 10ms?

Question

0.00/5 (No votes)

See more:

Now I need to do 3 things.
1. recorded those data to text file each 10ms.
2. communication get data and show on

C#

ListView

by RS485 each 10ms .
3. plot the data on my

C#

mschart

real time by 10ms.
I used

C#

[DllImport("winmm.dll")]

to get precision 10ms.
And I used 3 thread to do above jobs.
But now I found the text file's data not always 10ms,sometimes 20ms.
So how could I programming my code if I would like all the job run synchronous in each 10ms.
Thanks!

What I have tried:

<pre><pre> <pre>
mTimer1 = new TimePeriod();
threadWrite = new Thread(() =>
{
         mTimer1.AccurateTimer(this, new Action(WritetoTextFile), delay);
});
thread1.IsBackground = true;
thread1.Start();

mTimer2 = new TimePeriod();
thread2 = new Thread(() =>
{
   mTimer2.AccurateTimer(this, new Action(tmrChart_Tick), delay);
});
thread2.IsBackground = true;
thread2.Start();

mTimer3 = new TimePeriod();
threadDisplay = new Thread(() =>
{
      mTimer3.AccurateTimer(this, new Action(DisplayData), delay);
});
thread3.IsBackground = true;
thread3.Start();

Posted 17-Jun-19 22:27pm

astrosarah

Updated 18-Jun-19 0:38am

Add a Solution

Comments

F-ES Sitecore 18-Jun-19 4:34am

I think you'll struggle to do this with c#.

Maciej Los 18-Jun-19 4:44am

Seems, you don't need 3 timers. You need only one and 3 actions in it: 1) dump data, 2) read data, 3) plot on the chart.

johannesnestler 18-Jun-19 4:58am

Write to Textfile in 10ms - this won't work. Make it a consumer Producer-pattern and leave timers away. Do it as quickly as you can. "Real-time" Charts are no trivial topic...

Ralf Meier 18-Jun-19 6:24am

In my opinion this will not work 100% reliable at each time.
If you work with Timers or Tasks - if a method needs more than 10ms to complete it's work you could not guarantee this cycle-time - some actions will not be done at the same time (for example write data into the same file).

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

OriginalGriff · Answer 1 · 2019-06-18T00:38:00

Timers aren't reliable in the sense you think: when you specify an Interval you will not get a Tick event handler called exactly on that interval - you will get an event raised that will not be executed at less that the specified Interval but there is nothing in Windows that will force it to execute at that time - and worse, there is no real way of predicting exactly when the Tick handler will execute because it depends on the number of cores in the system, now many thread need to be serviced, and what else the system is doing.

And doing file based activity on a small interval is going to be fraught with delays anyway, because there is only one head drive to write all the output requests from all the applications and OS components which are writing to that drive. Yes, there are caches here, but generally they are quite small, and fill quickly - adding yet more delays to both the Timer processing and the write actions.

Worse, increasing the number of concurrent threads does not necessarily help, it can make it worse because each thread needs an available core to execute, and if the total threads in the whole system exceeds the number of cores, some will have to wait. Add more threads, and more have to wait. Since thread setup, switching, and scheduling takes core time as well adding thread can actually slow down throughput!