Raising an event at t0+dt

[Oriane]

Hi there,

I have to write an algorithm in .NET/C# which perform some task but has to
be stopped after an intreval of dT seconds. Something like:

dT = 30sec;
for (;;) {
t0 = GetCurrentTime ();
for (i=0;...) {
perform some operations;
if ( GetCurrentTime () t0 + dT)
break;
}
}

I intend to raise an event at t0+dT, but I don't know if it is posssible and
the best solution...

Any idea ?

Oriane

[Peter Duniho]

On Tue, 05 Jun 2007 00:58:30 -0700, Oriane <or****@guerman tes.frwrote:

I have to write an algorithm in .NET/C# which perform some task but has
to be stopped after an intreval of dT seconds. Something like:

dT = 30sec;
for (;;) {
t0 = GetCurrentTime ();
for (i=0;...) {
perform some operations;
if ( GetCurrentTime () t0 + dT)
break;
}
}

I intend to raise an event at t0+dT, but I don't know if it is posssible
and the best solution...

Make "dT" a TimeSpan value, set it to 30 seconds, then make "t0" a
DateTime value, setting it to DateTime.Now before the loop. Then of
course use DateTime.Now in the other place you have "GetCurrentTime ", and
you're all set.

I suppose you could instead use a timer and some sort of inter-thread
communication to handle the timing, but assuming your "perform some
operations" is non-trivial, I think it's fine to just poll the current
time between each operation.

Pete

[Oriane]

Hello Peter,

"Peter Duniho" <Np*********@nn owslpianmk.coma écrit dans le message de
news:op******** *******@petes-computer.local. ..
On Tue, 05 Jun 2007 00:58:30 -0700, Oriane <or****@guerman tes.frwrote:

I suppose you could instead use a timer and some sort of inter-thread
communication to handle the timing,

Yes anyway I will have a multi-threading application. I thought of using a
Timer, but I would have to destroy it after the first signal...

but assuming your "perform some operations" is non-trivial, I think it's
fine to just poll the current time between each operation.

So you are probably right, but I must add that the "perform some operations"
won't take me too long. What I mean is that if I wait for t0+dt, I will have
to make the thread sleep most of the time in the for loop. That's why it
would be more elegant to "prepare" an event to be raised at t0+dt before the
loop, quit the loop after the operations have been performed (so in most of
the case), then catch the event to close the job... So the Timer is a good
solution...

Pete

[Jon Skeet [C# MVP]]

On Jun 5, 12:22 pm, "Oriane" <ori...@guerman tes.frwrote:

Hello Peter,
On Tue, 05 Jun 2007 00:58:30 -0700, Oriane <ori...@guerman tes.frwrote:

I suppose you could instead use a timer and some sort of inter-thread
communication to handle the timing,

Yes anyway I will have a multi-threading application. I thought of using a
Timer, but I would have to destroy it after the first signal...

It's still going to be easier not to make this particular part single
threaded, I'd have thought.

....but assuming your "perform some operations" is non-trivial, I
think it's

fine to just poll the current time between each operation.

So you are probably right, but I must add that the "perform some
operations" won't take me too long. What I mean is that if I wait for t0+dt, I
will have to make the thread sleep most of the time in the for loop.

It's not clear what you want to happen at t0+dt. If the point was just
to make it a timeout - i.e. don't keep going if you get to that time -
then you don't need to sleep. Just put the check in after each
iteration of the loop, bailing out if you've reached that maximum
time. If you happen to finish before that time, I'd expect you to be
able to just return anyway.

If this isn't the case, perhaps you could give us some more
information?

That's why it would be more elegant to "prepare" an event to be raised at
t0+dt before the loop, quit the loop after the operations have been
performed (so in most of the case), then catch the event to close the job...
So the Timer is a good solution...

That sounds significantly more complicated to me - a solution in
search of a harder problem than you're really trying to solve.

Jon

[Ben Voigt [C++ MVP]]

"Oriane" <or****@guerman tes.frwrote in message
news:A9******** *************** ***********@mic rosoft.com...

Hi there,

I have to write an algorithm in .NET/C# which perform some task but has to
be stopped after an intreval of dT seconds. Something like:

dT = 30sec;
for (;;) {
t0 = GetCurrentTime ();
for (i=0;...) {
perform some operations;
if ( GetCurrentTime () t0 + dT)
break;
}
}

I intend to raise an event at t0+dT, but I don't know if it is posssible
and the best solution...

I'd use a waitable timer, but that's not really a .NET-centric solution.

>
Any idea ?

Oriane

[Oriane]

"Jon Skeet [C# MVP]" <sk***@pobox.co ma écrit dans le message de
news:11******** **************@ p77g2000hsh.goo glegroups.com.. .

On Jun 5, 12:22 pm, "Oriane" <ori...@guerman tes.frwrote:
It's still going to be easier not to make this particular part single
threaded, I'd have thought.

I have to use multi-thread since my app will be sent message from other
apps, with WCF. The "some operations" will mainly wait for these messages...

It's not clear what you want to happen at t0+dt. If the point was just
to make it a timeout - i.e. don't keep going if you get to that time -
then you don't need to sleep. Just put the check in after each
iteration of the loop, bailing out if you've reached that maximum
time. If you happen to finish before that time, I'd expect you to be
able to just return anyway.

Yes you are absolutely right, I'm not clear. I give you the context: my .NET
app is running on a PC which connected with several electronic devices.
These devices send data about "tags" on the fly. Each tag is RFID and will
send periodically (say every dT=30 seconds, but this depends on the tag !) a
signal, which will be processed on the devices and then immedialtely
transfered to the PC.

On the PC, I have to process each tag separately, mainly to conclude
something like: this tag was at position X,Y at time t0. Of course this
processing must be stopped after dT seconds (the period of the RFID) for
each tag (depending on the tag),

Now, what make things more complex, I have several PC, and a tag signal can
be received by several PC. So PC have to communicate with each other to
"make a agreement" on the position of the tage at t0, since there is always
a "noise" into the signal (and so a discrepancy between the PC), and the
calculated position is different according to each PC.

So, starting from T0 , I wait for the signal of the devices (plugged on the
USB), and from the other PC (with WCF over TCP or HTTP), I first recognize
the tag (so now I know dT, and I can eventually set a Timer), I make a very
short operations on these messages, and at t0+dT, I stop the processing.

Now I've tried to design an UML activity and sequence diagrams, but the fact
that there are several PC and a different period for each RFID prevents me
to finish it up to now (I keep trying !!).

>
If this isn't the case, perhaps you could give us some more
information?

I hope this was enough...

Oriane

[Jon Skeet [C# MVP]]

On Jun 5, 3:33 pm, "Oriane" <ori...@guerman tes.frwrote:

It's still going to be easier not to make this particular part single
threaded, I'd have thought.

I have to use multi-thread since my app will be sent message from other
apps, with WCF. The "some operations" will mainly wait for these
messages...

That doesn't mean that the bit which knows how long to process for
needs to be multi-threaded though.

It's not clear what you want to happen at t0+dt. If the point was just
to make it a timeout - i.e. don't keep going if you get to that time -
then you don't need to sleep. Just put the check in after each
iteration of the loop, bailing out if you've reached that maximum
time. If you happen to finish before that time, I'd expect you to be
able to just return anyway.

Yes you are absolutely right, I'm not clear. I give you the context: my .NET
app is running on a PC which connected with several electronic devices.
These devices send data about "tags" on the fly. Each tag is RFID and will
send periodically (say every dT=30 seconds, but this depends on the tag !)
a signal, which will be processed on the devices and then immedialtely
transfered to the PC.

On the PC, I have to process each tag separately, mainly to conclude
something like: this tag was at position X,Y at time t0. Of course this
processing must be stopped after dT seconds (the period of the RFID) for
each tag (depending on the tag),

Okay, that all sounds okay - but I'm not sure what's wrong with the
simple approach of:

1) Work out how long you're allowed to process for
2) For each iteration of the loop check whether you're still allowed
to process
3) Terminate when either you've finished processing, or the time
allotted has expired

It sounds an awful lot easier than using a timer, personally.

If that doesn't satisfy the requirements, could you give more details
about where it fails?

<snip>

Jon

[Oriane]

"Jon Skeet [C# MVP]" <sk***@pobox.co ma écrit dans le message de
news:11******** **************@ w5g2000hsg.goog legroups.com...

On Jun 5, 3:33 pm, "Oriane" <ori...@guerman tes.frwrote:

It's still going to be easier not to make this particular part single
threaded, I'd have thought.

I have to use multi-thread since my app will be sent message from other
apps, with WCF. The "some operations" will mainly wait for these
messages...

That doesn't mean that the bit which knows how long to process for
needs to be multi-threaded though.

Right

>

>Yes you are absolutely right, I'm not clear. I give you the context: my
.NET
app is running on a PC which connected with several electronic devices.

[snip]

>
Okay, that all sounds okay - but I'm not sure what's wrong with the
simple approach of:

1) Work out how long you're allowed to process for
2) For each iteration of the loop check whether you're still allowed
to process

I was afraid that comparing the current date and t0+dT would be "CPU
consuming" ?

3) Terminate when either you've finished processing, or the time
allotted has expired

It sounds an awful lot easier than using a timer, personally.

Ok.

If that doesn't satisfy the requirements, could you give more details
about where it fails?

No your solution meets my requirements. By the way, when I perform a
Thread.Sleep () operation on a thread, do I consume CPU resources ?

<snip>

Jon

[Jon Skeet [C# MVP]]

On Jun 5, 4:11 pm, "Oriane" <ori...@guerman tes.frwrote:

If that doesn't satisfy the requirements, could you give more details
about where it fails?

No your solution meets my requirements. By the way, when I perform a
Thread.Sleep () operation on a thread, do I consume CPU resources ?

Negligible, if any. But nothing in my recommended solution required a
sleep, as far as I could see...

Jon

[Oriane]

"Jon Skeet [C# MVP]" <sk***@pobox.co ma écrit dans le message de
news:11******** **************@ g4g2000hsf.goog legroups.com...

On Jun 5, 4:11 pm, "Oriane" <ori...@guerman tes.frwrote:
Negligible, if any. But nothing in my recommended solution required a
sleep, as far as I could see...

Yes but I will have to use it for the thread which will wait for a WCF
message (i.e wait for a attribute to change), or for the other thread which
will wait for the USB data.

Jon