// Reception of the data of tag #45
Original_Position of tag 45 = Function (data_tag#45); // this should
take less than 1"
t0 = GetCurrentTime ();
Interval dT = Function (#tag); // approximately 30"
while ( GetCurrentTime () < t0 + dT - 5") {
wait for message from other processes concerning tag #45;
}
Final_Position of tag 45 = Function (messages received,
Original_Position of tag 45 );
Okay, that's considerably different from my previous understanding of the
problem. Let me see if I can rephrase your design:
-- You receive some data regarding a specific "tag".
-- You have a function that, given the "tag", tells you how long you need
to receive _other_ data for the same "tag" in order to complete a reliable
position calculation.
-- You then sit around waiting for that _other_ data for the same "tag" to
arrive, so that it can be integrated into your position calculation.
-- When the time is expired, you then take all of the data you've received
and do a final calculation on the position of that "tag"
Do I have that right?
If so, then I would say that I see two good solutions, neither of which
poll the current time. Which one is more appropriate depends on how
exactly you're receiving the data.
IMHO, the best way to receive the data is to do so using asynchronous
methods. If you are doing that, then assuming you've got a main form
that's handling all the UI and management of the calculations, using the
Form.Timer class will allow you to specify a time in the future when you
want to be notified. When that timer expires, you can then take all of
the data received and process it.
The only tricky part in the above would be that you need to synchronize
access to whatever data structure is collecting the messages received, so
that while the form timer event is being executed, the receiving code
doesn't access the data received so far. That should be a simple "lock"
though.
If the data is not being received via asynchronous methods then either the
synchronous mechanism to receive data includes a timeout value or it
doesn't. If it does, then I would set the timeout value to the elapsed
time remaining. This would need to be updated each time a new synchronous
call to receive is made. Eventually you'll return from the receiving
function without having received anything (the timeout expired), and when
that happens you then process all the data you have so far.
If the method used to receive doesn't have a timeout mechanism, then
you'll have to choose between accepting that you may not get to process
your data received so far until well after the length of time you specify
(since you could attempt to receive and then block for some indefinite
period of time waiting for data), or converting your synchronous mechanism
to an asynchronous method (note that even if your method of receiving data
doesn't inherently support asynchronous receiving, you can do that
yourself by putting the receiving code into a separate thread).
All of the above is a bit vague intentionlly, because you haven't given us
any information as to how you actually receive data. It could be via a
variety of mechanisms, and so I don't want to make any assumptions about
what exactly you're doing. But hopefully the above gives you enough
information to go on.
Some final thoughts...
[...]
You already said that the processing itself is quick. Why would you
exceed dT?
Since messages could be sent from other PC after this delay...
I'm not sure how to interpret this reply to my question. However, one way
to interpret it is this: you are saying that you are using a blocking
mechanism to receive data, and that you may wind up waiting too long while
waiting to receive data, causing you do wait much longer than "dT" than
you want to before getting a chance to process the data received so far.
If that's the correct interpretation, then any of the options I suggest
above _except_ the non-timeout, blocking mechanism will fix that problem..
Oups ! I should write : " we CAN'T make a decision before dT seconds"
Ah. Yes, that's a critical change in meaning.
Pete
{