High-Priority Tasks

I have a C++ program I wrote as a pure DOS app, which would be fun to move to Windows. I used DOS because it is a real-time application, and must never be interrupted even for an instant by Windows deciding to clean up some files or something. My timing is crucial, and is controlled by reprogramming the timer chip. My smallest increment of time is 1/3600th of a second, and it must never be compromised. The program needs to tie up the computer for the duration, which could be an hour or more.

I found in the MS Knowledge Base a mention of setting the priority of a spawned task. There was a warning about the possibility of locking up the computer, no mouse response, etc, if you set something to the highest priority. That sounds like just what I need! While it's running, the only intervention I would ever want would be an emergency stop, which hopefully I could trigger through the printer port (which I'm already using for I/O).

Has anybody used these techniques? I'm not clear on how to implement it. Do I need all the time-critical code in a separate .exe which is spawned with high-pri? Then a front-end program would launch it, and regain control when it's done (or interrupted)? Then the front-end would be the only Windows app, and the spawned job would just be a number-cruncher and do the I/O. I guess the front-end would pass all the necessary properties via argv[]. Can the spawned job pass anything back to the front-end?

The most important question is, will it really work? Will the spawned job really lock out Windows but still communicate with the port?

Any insight will be greatly appreciated!

Sounds like you're doing something really specialist.

Yeh I guess you do as you suggest. I guess you could also obtain the tread id of your main process (see _threadid global variable) & assign highest priority to that.

However, I don't think Windows is really designed for this kind of thing. As you say everything will lock and, unless your application gives up control regularly, Windows will think your application has crashed. Even if you do give up control every so often, I don't see any guarantee of regaining control within an accuracy 1/3600 of second.

May be you could implement your solution in hardware & plug it into your PC in order to give it a nice GUI. I really don't know.

Thanks for quick reply!

I'll go into a little detail. The system controls two slide projectors though the printer port and a home-brew interface (a few logic gates and some triacs and opto-isolators). This is called "dissolve", when one projector fades out while the other fades in.

When you control the brightness of a projector lamp, you have to change what percentage of the 60hz cycle the lamp is on. It has to sync with the AC line or you get beating, which is VERY ugly. So the hardware also includes a zero-crossing detector which goes back through the port, to serve as a sync signal. I also control the timing of the whole presentation with the same signal, so the slides will sync with the CD-based soundtrack.

The DOS version works perfectly every time, has never once burped. But I suspect it would fail miserably under Windows. Yet it would be nice to have a nice Windows interface, and the program would be a lot easier to manage under mfc.

I thought of the hardware solution, but I'm not all that clever with electronics, and it would get pretty complicated. It would be far easier to fork over the bucks for a commercial programmable dissolve unit, but that would take all the fun out of DIY. So I keep thinking about the priority control under Windows...

I could give control back inbetween slide changes, but I fear that it might lose track of the time and mess up the slide sync.

I'll have to write a simple little program as an experiment, & see how Windows reacts to it.

If your high priority application ran for several seconds or so, then exited, it maybe possible.

As you say, you could spawn it somehow with high priority, from a seperate GUI application.

In this case, your high priority application should have no main window or console display. It should never call Sleep, or anything else which could hand CPU time to other processes. It should not rely on any other seperate threaded library or application. While it is running, your GUI application will not respond to input, nor (I guess) will other applications within Windows, or Windows itself.

With regard to getting info back to the GUI, your program could return an integer as result from the main function. Further information could be returned by some other form. For simplicity, I would suggest it writes a result file just before it exists, which can be read by you GUI once it regains control (if ever!).

Good luck.

this might not work. I have no ideas about how to do it.

If you could find a way to set all other process(even kernel) to a low prioriy, then set yours to high, that might give you the processor cycles that you need.

Are you setting your proceses to high or time critical?

The best you could probably do would be to use
SetThreadPriority(handle_of_thread, THREAD_PRIORITY_TIME_CRITICAL);

If you wanted to, you could set the other threads to the lowest possible level. Be careful though, this could mess up the comp if you aren't careful.