threads and Real-time processes

Since a process can be run in real-time on Windows, I don't see why the process/threads shouldn't be able to tell the OS how often or when it's allowed to switch out of a thread. i.e., if it's being run in real time, the consideration of a thread not exiting and blocking other apps on the computer is moot, so let the app do its own 'cooperative multitasking'.

also, for a real-time app you should be able to define which cores and cpus your threads and processes execute on. let's say you have four cores. you could make four threads or processes, but there's no guarantee they'll go on the respective cores, or that if they do they'll stay there. if you were running an app in real-time and wanted the greatest parallel efficiency, that wouldn't do.

but i'm not trying to suggest how an operating system should be made, my question is.. Can these things be done in windows?

also, i need to know about doing these in *nix systems.

Windows 3.11 and prior did just that, cooperative muyltitasking. The problem is that a poorly written applications can effectively crash the computer. The problem is if you fail to yield the processor, you can end up with resource lock, where your aplication cant get to the yield statement because it is waiting on disk i/o and the OS cant perform disk i/o until yoru application yields. Cooperative multitaskign doesnt give you the performance increase you think it will, and it makes the system unstable.

Windows 95 and higher use preemtpive multitasking, which improves performance considerably. As for specifying which core to run it on, you can, use SetProcessAffinityMask() SetThreadAffinityMask() and/or SetThreadIdealProcessor();

Quote:

---

Originally Posted by inhahe

Since a process can be run in real-time on Windows, I don't see why the process/threads shouldn't be able to tell the OS how often or when it's allowed to switch out of a thread. i.e., if it's being run in real time, the consideration of a thread not exiting and blocking other apps on the computer is moot, so let the app do its own 'cooperative multitasking'.

---

I think abachler already beat me to this one - it's impossible for each thread or process to know what else is important in the system. Some other application may also have important, real-time work to be done. Obviously, if this causes the system to be overloaded, the system isn't capable of running both at the same time, and some other solution must be found.

Quote:

---

also, for a real-time app you should be able to define which cores and cpus your threads and processes execute on. let's say you have four cores. you could make four threads or processes, but there's no guarantee they'll go on the respective cores, or that if they do they'll stay there. if you were running an app in real-time and wanted the greatest parallel efficiency, that wouldn't do.

---

This is available in both Windows and Linux using their process/thread affinity functions.
Of course, again, it's only useful for one or maybe two processes to do this, because if you have many threads competing for the same cpu(core), if any other cpu(core) is idle, we're actually wasting processing time by NOT running it on the idle core.

In a normal situation, in a quad core system, four threads would run, without any special settings on the four different cores. The only difference the affinity settings make is that the individual thread is not allowed to move away from that core. This is beneficial for processes/threads that use larger amounts of memory such that the processor's caches are important to the performance, and "throwing away" the cache-content is worse than missing a bit of execution time when that particular processor is busy on some other task (e.g. a system task, such as reading/writing to the disk or sending/receiving packets on the network).

Quote:

---

but i'm not trying to suggest how an operating system should be made, my question is.. Can these things be done in windows?

---

Sort of, as I described above.

Quote:

---

also, i need to know about doing these in *nix systems.

---

The exact names of the system functions to set affinity, or otherwise manipulate processes and threads are slightly different, but overall, the functionality is identical (or at least so near that it's not meaningful to differentiate it).

--
Mats

ok, i see. so you're saying i could just assign threads (1 per core) and not worry about which cores they're running on since if the threads are not idling, and all other threads are which is usually the case, they'll be distributed among the cores anyway. the only thing i worry about with this situation is if one core ends up doing some cpu-intensive task for some other application and my app ends up with two threads on one core. since the only purpose for using threads might be to use multiple cores/cpus, having 2 of my threads running on one of the cores would just be a waste of overhead.. should i worry about this? if i do i guess i could either use the affinity functions, or somehow detect how many cores are being used by my threads and then kill threads accordingly, but then it would be a different animal to know when to start a new thread..

Under WIndows, the affinity mask is only a suggestion. The OS will 'try' to schedule the thread on teh specified cpu, but it will schedule it on another one if the desired one is busy. Generally, just start 1 thread per processor and let windows handle the scheduling, it will almost always do a much better job of it than you. It inherently tries to keep a thread on the same core it was on last anyway.

Quote:

---

Originally Posted by abachler

Under WIndows, the affinity mask is only a suggestion. The OS will 'try' to schedule the thread on teh specified cpu, but it will schedule it on another one if the desired one is busy. Generally, just start 1 thread per processor and let windows handle the scheduling, it will almost always do a much better job of it than you. It inherently tries to keep a thread on the same core it was on last anyway.

---

At least in the latest versions (XP (service pack 2?) and Vista) - Win2K would very happily switch from one processor to the next for no reason whatsoever (other than it needed to schedule some other process - it obviously will not move a running thread when there is nothing else to run).

--
Mats