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
22  1361 
On Tue, 05 Jun 2007 00:58:30 -0700, Oriane <or****@guermantes.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
Hello Peter,
"Peter Duniho" <Np*********@nnowslpianmk.coma écrit dans le message de
news:op***************@petes-computer.local...
On Tue, 05 Jun 2007 00:58:30 -0700, Oriane <or****@guermantes.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
On Jun 5, 12:22 pm, "Oriane" <ori...@guermantes.frwrote:
Hello Peter,
On Tue, 05 Jun 2007 00:58:30 -0700, Oriane <ori...@guermantes.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
"Oriane" <or****@guermantes.frwrote in message
news:A9**********************************@microsof t.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
"Jon Skeet [C# MVP]" <sk***@pobox.coma écrit dans le message de
news:11**********************@p77g2000hsh.googlegr oups.com...
On Jun 5, 12:22 pm, "Oriane" <ori...@guermantes.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
On Jun 5, 3:33 pm, "Oriane" <ori...@guermantes.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
"Jon Skeet [C# MVP]" <sk***@pobox.coma écrit dans le message de
news:11**********************@w5g2000hsg.googlegro ups.com...
On Jun 5, 3:33 pm, "Oriane" <ori...@guermantes.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
On Jun 5, 4:11 pm, "Oriane" <ori...@guermantes.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
"Jon Skeet [C# MVP]" <sk***@pobox.coma écrit dans le message de
news:11**********************@g4g2000hsf.googlegro ups.com...
On Jun 5, 4:11 pm, "Oriane" <ori...@guermantes.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
On Jun 5, 4:22 pm, "Oriane" <ori...@guermantes.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.
Okay, that's fine - although depending on how you're receiving the
data, you may find there are blocking calls or using Monitor.Wait/
Pulse might be a better idea.
Jon
On Tue, 05 Jun 2007 07:33:51 -0700, Oriane <or****@guermantes.frwrote:
[...]
>If this isn't the case, perhaps you could give us some more
information?
I hope this was enough...
After all that, I'm still not entirely clear on why you feel there's a
need to "stop processing" after 30 seconds. You say that the processing
itself requires minimal time, far less than 30 seconds (or any specific
length of time). It's not clear to me why you cannot just implement your
code to receive a message, process the data, and then go back to waiting
for another message.
If your question has been answered at this point, then I suppose further
clarification would be pointless. But there's something about your
description of the problem that makes me suspect that there are some
fundamental misunderstandings on your part about how the design of your
code should be done. It's just a "hunch", but there's nothing about the
task you say you're doing that so far explains to me why there's any need
for checking the time.
Pete
"Jon Skeet [C# MVP]" <sk***@pobox.coma écrit dans le message de
news:11*********************@n4g2000hsb.googlegrou ps.com...
On Jun 5, 4:22 pm, "Oriane" <ori...@guermantes.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.
Okay, that's fine - although depending on how you're receiving the
data, you may find there are blocking calls or using Monitor.Wait/
Pulse might be a better idea.
I saw the SDK documentation for Monitor.Pulse/Wait ban I can't see how I
could use this paradigm to wait for a change in a global variable.
By the way another basic question: is the heap shared between threads ? I
guess yes...
Thanks again for your help.
Regards
Hello Pete,
"Peter Duniho" <Np*********@nnowslpianmk.coma écrit dans le message de
news:op***************@petes-computer.local...
On Tue, 05 Jun 2007 07:33:51 -0700, Oriane <or****@guermantes.frwrote:
It's not clear to me why you cannot just implement your code to receive a
message, process the data, and then go back to waiting for another
message.
because the processing has to wait for messages from other processes during
dT. It is a constraint.
>
If your question has been answered at this point, then I suppose further
clarification would be pointless. But there's something about your
description of the problem that makes me suspect that there are some
fundamental misunderstandings on your part about how the design of your
code should be done. It's just a "hunch", but there's nothing about the
task you say you're doing that so far explains to me why there's any need
for checking the time.
I thought that my answer to Jon was clear enough. The goal is to compute the
position of an object every dT seconds. So we can't exceed dT seconds to
process the data sent by the bus. On the other hand, other processes can
send data within dT, so we can make a decision before dT seconds.
Oriane
On Jun 6, 8:48 am, "Oriane" <ori...@guermantes.frwrote:
Okay, that's fine - although depending on how you're receiving the
data, you may find there are blocking calls or using Monitor.Wait/
Pulse might be a better idea.
I saw the SDK documentation for Monitor.Pulse/Wait ban I can't see how I
could use this paradigm to wait for a change in a global variable.
Whatever changes the variable would need to pulse the monitor;
whatever is waiting for the change would need to wait on the monitor.
By the way another basic question: is the heap shared between threads ? I
guess yes...
Yes.
Jon
On Wed, 06 Jun 2007 00:53:36 -0700, Oriane <or****@guermantes.frwrote:
>It's not clear to me why you cannot just implement your code to
receive a message, process the data, and then go back to waiting for
another message.
because the processing has to wait for messages from other processes
during dT. It is a constraint.
Why can't you just always be waiting for messages from all "processes".
(Also, you seem to be using the word "process" to describe your
devices...why that is, I don't know, but this is the first time you've
mentioned getting messages from "processes", and you _have_ been talking
about devices, so I'm assuming that that's what you mean when you write
"processes". Do keep in mind that in Windows, a "process" is a very
specific thing, and applications almost never have to deal with messages
from other processes).
I thought that my answer to Jon was clear enough.
No doubt. But as you can see, you're confusing at least one person.
The goal is to compute the position of an object every dT seconds. So we
can't exceed dT seconds to process the data sent by the bus.
You already said that the processing itself is quick. Why would you
exceed dT?
On the other hand, other processes can send data within dT, so we can
make a decision before dT seconds.
Why can you not do your processing on a dedicated "position calculation"
thread, and let the i/o stuff continue to receive data from the other
devices (or even the one from which you most recently received data, for
that matter)?
I mean, I guess the easiest thing to do is answer the basic questions and
let you figure out how that all gets crammed into your program. But I'm
still not seeing the need for any sort of timing at all.
Pete
"Peter Duniho" <Np*********@nnowslpianmk.coma écrit dans le message de
news:op***************@petes-computer.local...
On Wed, 06 Jun 2007 00:53:36 -0700, Oriane <or****@guermantes.frwrote:
Why can't you just always be waiting for messages from all "processes".
The algorithm could be something like this (some names are invented !!!)
// 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 );
>I thought that my answer to Jon was clear enough.
No doubt. But as you can see, you're confusing at least one person.
:-)) I would like to show you a schema.
>The goal is to compute the position of an object every dT seconds. So we
can't exceed dT seconds to process the data sent by the bus.
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...
>On the other hand, other processes can send data within dT, so we can
make a decision before dT seconds.
Oups ! I should write : " we CAN'T make a decision before dT seconds"
Why can you not do your processing on a dedicated "position calculation"
thread, and let the i/o stuff continue to receive data from the other
devices (or even the one from which you most recently received data, for
that matter)?
Yes... But this could be done in the same thread (see my pseudo code) since
the "postipon computation" is very fast.
I mean, I guess the easiest thing to do is answer the basic questions and
let you figure out how that all gets crammed into your program. But I'm
still not seeing the need for any sort of timing at all.
Yes. This is mainly because I gave you wrong or incomplete informations.
Basically, I need to make things clear in my mind (hard stuff, believe me
!!). The example I gave you is not complete since a process could be sent
message before receiving data from the USB (connected to electronic
devices).Concerning the pure .NET aspect, now it's allright, I agree with
you: I don't need a timer.
Oriane
You said you will receive the next data from your device after 30 seconds.
Then why not:
Store the data received from the device.
do forever {
Store messages received from the other PCs.
When the next message from the device comes, process all stored messages,
then erase all stored data and store the newly received data.
}
This is entirely event driven and doesn't require any explicit waits. If
you want a timeout when the device data doesn't update for too long, then
request a message/event after the interval expires, using WM_TIMER or a
waitable timer.
Do these messages come with any sequence number or synchronized timestamp
that you can use to match them up?
On Wed, 06 Jun 2007 01:49:24 -0700, Oriane <or****@guermantes.frwrote:
// 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..
>>On the other hand, other processes can send data within dT, so we can
make a decision before dT seconds.
Oups ! I should write : " we CAN'T make a decision before dT seconds"
Ah. Yes, that's a critical change in meaning. :)
Pete
"Peter Duniho" <Np*********@nnowslpianmk.coma écrit dans le message de
news:op***************@petes-computer.local...
On Wed, 06 Jun 2007 01:49:24 -0700, Oriane <or****@guermantes.frwrote:
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?
Correct.
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.
Yes that was my first intention. But this is considered as not optimal by
Jon...and I agree with him !
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.
Yes. The data will be changed by 2 threads (running WCF + an USB driver),
ans will be enqueud in a class/global variable. Jon thinks that I should
using a Monitor (Pulse/Wait).
[snip]
[...]
>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.
Correct
Regards
On Jun 7, 8:42 am, "Oriane" <ori...@guermantes.frwrote:
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.
Yes that was my first intention. But this is considered as not optimal by
Jon...and I agree with him !
Well, I was considering the situation when I just thought the problem
was "keep processing until a particular time". If it makes the code
simpler to wait until a particular time and then process everything
you've received so far, then a timer could well be a good way of
proceeding.
Jon
Correction:
"Oriane" <or****@guermantes.fra écrit dans le message de
news:uF**************@TK2MSFTNGP06.phx.gbl...
>
"Peter Duniho" <Np*********@nnowslpianmk.coma écrit dans le message de
news:op***************@petes-computer.local...
On Wed, 06 Jun 2007 01:49:24 -0700, Oriane <or****@guermantes.frwrote:
Yes. The data will be changed by 2 threads (running WCF + an USB driver),
ans will be enqueud in a class/global variable. Jon thinks that I should
using a Monitor (Pulse/Wait).
The data (that is the position of the tags) will be received by two
different threads (anyway I need one for the WCF channel) and will be
enqueued in a class/global variable. The "main thread" will then dequeued
them and make computation.
On Thu, 07 Jun 2007 00:49:48 -0700, Oriane <or****@guermantes.frwrote:
The data (that is the position of the tags) will be received by two
different threads (anyway I need one for the WCF channel) and will be
enqueued in a class/global variable. The "main thread" will then
dequeued them and make computation.
Then it seems to me that a Forms.Timer is exactly what you need. Just
don't forget to lock the data queue when the main form thread is dequeuing
the data, and when the receiving threads are enqueing the data. However,
since you should already be doing that now, I'm guessing that's not an
issue for you.
Though, that said there is one caveat: due to the way that Windows works,
none of the timers are particularly accurate, and the Forms.Timer is the
least accurate. It has a resolution of (according to the documentation)
only 55 milliseconds. In some applications, this would be unacceptable.
It sounds to me as though you're dealing with much larger time values than
that, and an error of 55 milliseconds isn't a problem. But if it is,
you'll have to use a different Timer class (there are two others).
Pete This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Oriane |
last post by:
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...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
