Because of other programs being used, I can't use a cmd line to shutdown my computer after a certain amount of time. I have tried using the task scheduler to shutdown the computer after idle for x amount of time, but it doesn't work.
Do I have to kill the processes too going on in the background too? If so, how?
You can use the power options in the configuration panel for putting your computer to sleep when idle for a certain time.
Related
Is an application running in a console window treated "less important" by the windows scheduler, i.e. does Windows allow it to "sleep" longer if it's minimized? I thought I read something about Windows lowering its priority if it's minimized, but perhaps I just mixed something up.
The thing is, I have a C console app (written in VS2015, but running on Windows Server 2008 R2, so no GetSystemTimePrecise support, unfortunately), which does some socket communication, but sometimes the receiving threads (IOCP) get paused and packets get merged together.
So, in my main function I wrote something like this:
timeBeginPeriod(1);
while (true)
{
QueryPerformanceCounter(&start);
Sleep(1);
QueryPerformanceCounter(&stop);
LogTimeElapsed(start, stop);
}
I obviously didn't expect to get millisecond accuracy out of Sleep(1), but I was surprised to get numerous delays of ~50 milliseconds, with maximum reaching more than 120 milliseconds on several occasions.
Of course, during this time, there were other active processes consuming CPU (doing some database exporting and similar, with total CPU going to ~50%), but since this is a quad core CPU I thought that the thread scheduler would still prevent such long delays from happening.
Is this an artifact of running as a plain console app, or should I expect similar delays in any Windows desktop/service application?
Windows is not a real time system, so it is allowed to suspend a task for a non deterministic time. If other tasks use the 4 cores during a short time (some tenths of seconds) any program (be it console of GUI) can be suspended for that time. And as Windows is a feature rich OS, many system services can compete for the CPU in addition to other tasks, so latencies up to few tenths of seconds can be expected at any time
Simply the TCP stack guarantees that the program will get all the data received during that time in correct order, but it is allowed to concatenate several packets in on single read because TCP is a stream protocol. So you program should be prepared for that. The only alternative is to use a real time OS, either on the main machine or on a dedicated one.
I am experimenting with SCHED_FIFO and I am seeing some unexpected behaviour. The server I am using has 12 cores with hyper-threading disabled. All configurable interrupts have been set to run on CPU 0.
My program starts creates a thread for lower priority tasks using the pthreads library without changing the scheduling policy with CPU affinity set to core 0. The parent thread then sets its CPU affinity to core 3 and its own scheduling policy to SCHED_FIFO using sched_setscheduler() with pid zero and priority 1 and then starts running a non-blocking loop.
The program itself runs well. However, if I attempt to log into the server for a second time while the program is running the terminal is unresponsive until I stop my program. It is like the scheduler is trying to run other processes on the same core as the real time process.
What am I missing?
Will the scheduler still attempt to run other processes on a core running a real time process? If so, is there a way to prevent this?
Will setting the scheduling policy with sched_setscheduler() in the parent change the behaviour of the child that was created before?
Thanks in advance.
sched_setscheduler sets the scheduler of the process, not the thread. See:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/sched_setscheduler.html
If you want to set the scheduler for a thread, you need to use the pthread_attr_setschedpolicy and pthread_attr_setschedparam functions on the attribute object for the new thread before you create it.
I'm not sure how conformant Linux is on honoring these requirements, but you should at least start out by making sure your code is correct to the specification, then adjust it as needed...
I have a WPF program that communicates with a specialized USB stick that is collecting data (in fact an ANT USB dongle). I noticed that the data collection simply stopped after a few hours. The reason was evident in the windows logs (system) where at the exact time the program stopped getting data, I see:
The system is entering sleep
Sleep Reason: System Idle
Questions
How do I programmatically prevent Windows from going to sleep so that I can continue to gather data?
2. Stepping backwards for the big picuture view... What's going on? Why does the computer going to sleep affect my program? Or is it just affecting the USB stick? Is it necessary to prevent sleep or should I do something else instead?
Einstein's answer is tantalizingly close. I just can't seem to get SetThreadExecutionState working in my C#/WPF program and can't find a lot of examples or discussions of it. Does it need to be called more than once? If so how? Is there a event that I receive that tell me to call it or should I call it every so often (5 minutes?) as suggested in:http://stackoverflow.com/questions/5870280/setthreadexecutionstate-is-not-working-when-called-from-windows-service
For now, I'm just going into ctrl panel -> power options and preventing sleep but it would sure be nice to have an elegant solution. Even on my own computer, I don't want to mess with the sleep settings. It's too hard to remember to set them back again!
You can prevent the computer from entering low power modes (sleep/suspend) by using the SetThreadExecutionState function.
As far as why going into low power mode is interrupting your data collection - well Windows suspends all processes in these modes and USB ports enter low power mode which likely means your USB device will not have power either. It's by design. After all, the whole reason we want our computers to go to sleep is so that the battery is not drained.
You can apply the above responses, o simply you can go in Control Panel -> Power Options and modify the settings, so your system never goes to sleep.
To 1): You can use SystemParametersInfo with one of the power related values on Windows versions less than Vista to turn on/off power savings settings. Starting with Vista, you should register for one of the power events instead, and the OS will notify you when it needs to for the event you request.
To 2): If the OS shuts down, the hardware it's managing shuts down. What else would you expect to happen? If the OS runs the USB device driver, which runs the USB device, what would you think would happen if the OS goes to sleep? The USB device begins running itself instead without the driver?
I have an system running embedded linux and it is critical that it runs continuously. Basically it is a process for communicating to sensors and relaying that data to database and web client.
If a crash occurs, how do I restart the application automatically?
Also, there are several threads doing polling(eg sockets & uart communications). How do I ensure none of the threads get hung up or exit unexpectedly? Is there an easy to use watchdog that is threading friendly?
You can seamlessly restart your process as it dies with fork and waitpid as described in this answer. It does not cost any significant resources, since the OS will share the memory pages.
Which leaves only the problem of detecting a hung process. You can use any of the solutions pointed out by Michael Aaron Safyan for this, but a yet easier solution would be to use the alarm syscall repeatedly, having the signal terminate the process (use sigaction accordingly). As long as you keep calling alarm (i.e. as long as your program is running) it will keep running. Once you don't, the signal will fire.
That way, no extra programs needed, and only portable POSIX stuff used.
The gist of it is:
You need to detect if the program is still running and not hung.
You need to (re)start the program if the program is not running or is hung.
There are a number of different ways to do #1, but two that come to mind are:
Listening on a UNIX domain socket, to handle status requests. An external application can then inquire as to whether the application is still ok. If it gets no response within some timeout period, then it can be assumed that the application being queried has deadlocked or is dead.
Periodically touching a file with a preselected path. An external application can look a the timestamp for the file, and if it is stale, then it can assume that the appliation is dead or deadlocked.
With respect to #2, killing the previous PID and using fork+exec to launch a new process is typical. You might also consider making your application that runs "continuously", into an application that runs once, but then use "cron" or some other application to continuously rerun that single-run application.
Unfortunately, watchdog timers and getting out of deadlock are non-trivial issues. I don't know of any generic way to do it, and the few that I've seen are pretty ugly and not 100% bug-free. However, tsan can help detect potential deadlock scenarios and other threading issues with static analysis.
You could create a CRON job to check if the process is running with start-stop-daemon from time to time.
use this script for running your application
#!/bin/bash
while ! /path/to/program #This will wait for the program to exit successfully.
do
echo “restarting” # Else it will restart.
done
you can also put this script on your /etc/init.d/ in other to start as daemon
I am in a real fix. Please help. Its urgent.
I have a host process that spawns multiple host(CPU) threads (pthreads). These threads in turn call the CUDA kernel. These CUDA kernels are written by external users. So it might be bad kernels that enter infinite loop. In order to overcome this I have put a time-out of 2 mins that will kill the corresponding CPU thread.
Will killing the CPU thread also kill the kernel running on the GPU? As far as what I have tested it does'nt.
How can I kill all the threads currently running in the GPU?
Edit: The reason I am using CPU threads that call the kernel is because, the sever has two Tesla GPU's. So the thread will schedule the kernel on the GPU device alternatively.
Thanks,
Arvind
It doesn't seem to. I ran a broken kernel and locked up one of my devices seemingly indefinitely (until reboot). I'm not sure how to kill running kernel. I think there is a way to limit kernel execution time via the driver, though, so that might be the way to go.
Unless there's a larger part of this I'm not really getting, You might be better off using CUDA Streams api for multi-device tasking, but YMMV.
As for the killing; if you're running the cards with a display (and x server) attached, they will automatically timeout after 5 seconds (again, YMMV).
Assuming that this isn't the case; check out calling cudaDeviceReset() API Reference; from the 'parent' thread after your own prescribed 'kill' timeout.
I have not implemented this function in my own code yet so honestly have no idea if it'll work in your situation, but its worth investigation.
Will killing the CPU thread also kill the kernel running on the GPU? As far as what I have tested it does'nt.
Probably not. On Linux u can use cuda-gdb to figure that out.
I don't see the point of sending multiple kernels to the GPU using threads.. I wonder what happens if you send multiple Kernels to the GPU at time.. Will the thread scheduler of the GPU deal with that?