@swampdog
I certainly misunderstand a lot of things, not only threads. To answer a couple of your questions: it would be a GUI program, part of a control system where the user can set some configuration parameters, among others timers, and the program will, among other things, switch things on and off at the times given by those parameters.
Think like: fan1 has to be on for t1 and then off for t2, light1 has to be on for t3 and then off for t4, motor1 has to run for t5 in one direction, for t6 in the other direction and then change direction again, and so on. The timing doesn't have to be awfully accurate: a drift of a few hundredth of a second are not a problem.
The things I found are quite a few, for instance this https://stackoverflow.com/questions/109 ... mer-in-c-c or this https://www.fluentcpp.com/2018/12/28/timer-cpp/.
Like you said, I don't understand much about threads (or about anything else, for that matter, I haven't even started coding anything yet, so you can't even call me a beginner![:D]( "Very Happy")
), but if the idea I get by reading these is correct:
- Take the thread for the fan, for instance. It would have to run forever, waiting (sleeping for) t1, then switching the fan off, sleep for t2 then switch the fan on and looping like that forever. This thread will never return until someone pushed the "off" button. With my poor understanding of the thing, if I start having a lot of timers that all work this way, I may run out of CPU cores and the OS would have to schedule them somewhat funny, thereby kicking the "timing" function of them to the moon (not really, I expect the drift to still be acceptable, but I guess you understand what I mean).
- Another way I see is having two threads: one that switches the fan on and one that switches it back off. That way the threads would return each time, thereby freeing their resources, but the "main" would have to take care to call the "fan on" and "fan off" functions and send them to a thread in rapid succession. If it's busy doing other things, there could be some delay and, again, the timing could end up being too much off (not for my purpose, I expect, but for a general useful function of timers).
As ttapa said:
I would be glad to stand corrected on the above, if that is not the way it works, as I like to learn (and I'm just starting). In the meantime I'll look into that ASIO stuff. Thanks for the lead.
If anyone has a better idea...
I certainly misunderstand a lot of things, not only threads. To answer a couple of your questions: it would be a GUI program, part of a control system where the user can set some configuration parameters, among others timers, and the program will, among other things, switch things on and off at the times given by those parameters.
Think like: fan1 has to be on for t1 and then off for t2, light1 has to be on for t3 and then off for t4, motor1 has to run for t5 in one direction, for t6 in the other direction and then change direction again, and so on. The timing doesn't have to be awfully accurate: a drift of a few hundredth of a second are not a problem.
The things I found are quite a few, for instance this https://stackoverflow.com/questions/109 ... mer-in-c-c or this https://www.fluentcpp.com/2018/12/28/timer-cpp/.
Like you said, I don't understand much about threads (or about anything else, for that matter, I haven't even started coding anything yet, so you can't even call me a beginner
), but if the idea I get by reading these is correct:- Take the thread for the fan, for instance. It would have to run forever, waiting (sleeping for) t1, then switching the fan off, sleep for t2 then switch the fan on and looping like that forever. This thread will never return until someone pushed the "off" button. With my poor understanding of the thing, if I start having a lot of timers that all work this way, I may run out of CPU cores and the OS would have to schedule them somewhat funny, thereby kicking the "timing" function of them to the moon (not really, I expect the drift to still be acceptable, but I guess you understand what I mean).
- Another way I see is having two threads: one that switches the fan on and one that switches it back off. That way the threads would return each time, thereby freeing their resources, but the "main" would have to take care to call the "fan on" and "fan off" functions and send them to a thread in rapid succession. If it's busy doing other things, there could be some delay and, again, the timing could end up being too much off (not for my purpose, I expect, but for a general useful function of timers).
As ttapa said:
Another possibility I thought of, and this is the reason of my question to start with, is taking the time when something starts, like the fan goes on, and compare it at each cycle of the program with the current time. If t1 has elapsed, switch the fan off, otherwise keep going through the rest of the instructions. Of course that too isn't very accurate as a timer, because there's no telling how long the program will take to complete one round and start from the beginning, but at least it would save me the trouble of thread programming.That said, using an entire thread just to put it to sleep is rather wasteful.
I would be glad to stand corrected on the above, if that is not the way it works, as I like to learn (and I'm just starting). In the meantime I'll look into that ASIO stuff. Thanks for the lead.
If anyone has a better idea...
Statistics: Posted by elrkoxo — Sun Dec 08, 2024 10:15 am