Thread and Class Priorities for Real Time Data in MFC

In a multithreaded MDI MFC app, I load a (non MFC) dll that I wrote which uses _inp and _outp to drive an A/D board.  This is used in a university educational physics experiment.  The problem is that the time dependent sampling that the card does is apparently interrupted by the multitasking, and the signal becomes "broken" in time.  No noise is measured, it's just that the measurement stops and then restarts again,with no data being recorded during the lapse.

The question:  How do I suspend all other processes being handled by the os, and instruct it to ONLY run one particular thread?  ie, in general turn a Win95/98 computer into a real time data acquisition machine run through an MFC app.  The sampling lasts milliseconds to seconds at most.

the "proof" of the problem being the multitasking is that when the mouse is dragged, cpu time is used, and the signal becomes more broken.  When the mouse is held still, the signal is "mostly" continuous, but some other threads are still happening apparently..

I believe the best example to use for this is the MTRECALC sample that comes with VC++.  In the document class, when the worker thread is begun, I thought this would be the way to do it:  setting the ClassPriority and ThreadPriority to realtime for the duration of the calculation:

HANDLE CurProc=OpenProcess(PROCESS_ALL_ACCESS,TRUE,GetCurrentProcessId());
  BOOL ret=SetPriorityClass(CurProc,REALTIME_PRIORITY_CLASS);

  m_pRecalcWorkerThread =

  int prio = GetThreadPriority(m_pRecalcWorkerThread->m_hThread);
//this returns 15

  DWORD wrd = GetPriorityClass(CurProc);
//but this returns 256!!

then setting the Class priority back when the thread finishes, to allow for normal program flow.

So, what am I doing wrong?  Even during the calculation, the mouse and controls work.  I need the cpu dedicated to a specific loop for the duration of that loop, period.  

How do I do that?

Who is Participating?
jhanceConnect With a Mentor Commented:
Here are some references.  These are both NT specific but most of the issues with real-time performance are even worse with Win9x.  NT is fully preemptive where Win9x is NOT.  When Win9x is running real-mode (and it does about 25% of the time) it doesn't preempt at all.  This causes many real-time problems.  Under Win9x, you can write a VxD which will help but you cannot guarantee ANY maximum event response time under any version of Windows.  This is the difference between a RTOS and a non-RTOS.  Any RTOS will have a spec for the maximum event latency.

Windows NT and Real-Time Operating Systems
Last reviewed: May 6, 1997
Article ID: Q94265  
The information in this article applies to:
Microsoft Windows NT operating system version 3.1
Microsoft Windows NT Advanced Server version 3.1

You can use a variety of criteria to measure the performance of a real-time system. The following are examples of the kinds of measurements that might be used to determine real-time throughput:

Longest critical region that the kernel blocks task activation during a system call
Maximum time that interrupts are disabled
Context switch time (scheduler time to save/restore registers, etc.) for threads within the same process (no change in memory context) and for threads in different processes (save/restore memory context)
Interrupt response time (latency between the occurrence and execution of the first instruction)
Interrupt task response time (worst case task dispatch latency for task waiting on the interrupt)
Performance of interprocess communication facilities (semaphores, queues, pipes, etc.)

Because such specifics are hard to measure, this article provides a general discussion of the suitability of Windows NT as a real-time system.

Users often want a total program development/GUI user environment, virtual memory, and so forth, without any corresponding reduction in response time. Real-time systems, however, are dedicated systems for the duration of an "event." During that time, the system is essentially locked, and no other activity can take place except that real-time event. (Note that very few situations demand microsecond or millisecond response time.)

Windows NT has the same basic structure as VMS. Windows NT has more efficient mechanisms than RSX-11M. It has a better design than VAXELN, which is a real-time embedded OS toolkit. All three of these systems are very successful.

Although Windows NT has good real-time capabilities; it is not designed to compete with a special purpose real-time system. If you need such a system, obtain the special real-time hardware and supporting operating system.



Additional query words: prodnt real time realtime winnt
Keywords : kbother ntgeneral
Version : 3.1
Platform : WINDOWS


Last reviewed: May 6, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.

Real-Time Systems and Microsoft Windows NT
Microsoft Corporation

June 29, 1995

Real-Time Applications
Among the many types of common applications for which computers are used, the most familiar are personal productivity applications or various business applications. There are also high- performance, embedded applications that are often called upon to manage time-critical responses. These are among the most demanding of applications. These applications not only need to respond correctly; they also need to respond within certain specified time parameters, or in "real time." Examples of these applications include:

Manufacturing process controls

Medical monitoring equipment

Telecommunications switching equipment

High-speed data acquisition devices

Aircraft fly-by-wire controls
Definition of Real-Time Systems
There are many ways to define a real-time system. Perhaps one of the most comprehensive definitions is: "A real-time system is one in which the correctness of the computations not only depends upon the logical correctness of the computation, but also upon the time at which the result is produced. If the timing constraints of the system are not met, system failure is said to have occurred." (The source for this definition is the real time FAQ in the Internet's comp.realtime news group.)

As an example, consider the bottling equipment in a beverage plant. It's not sufficient if the equipment attempts to cap bottles at regular time intervals. If it's off by just a fraction of a second, then the bottle may not be capped properly and the beer will be spoiled. That is, the time at which the machine caps the bottle is a critical part of the process.

Practically speaking, this means that real-time applications fall into two primary groups—those that can respond in "hard" real-time, and other "soft" real-time applications with less severe requirements. Simply stated, a hard real-time operating system must, without fail, provide a response to some kind of event within a specified time window. This response must be predictable and independent of other activities undertaken by the operating system. Providing this response implies that system calls will have a specified, measured latency period. Hard real-time systems often employ specific hardware devices with special device drivers.

Under this definition, Microsoft® Windows NT™ Workstation is not a hard real-time operating system. Rather, it is a general-purpose operating system that has the capability to provide very fast response times, but is not as deterministic as a hard real-time system.

In contrast, a soft real-time operating system is one that has reduced constraints on "lateness," but still must operate quickly within fairly consistent time constraints. That is, it must be good enough to service events so that the response should be satisfied, on average. Windows NT meets this definition.

In summary, there are very few applications that require a true real-time operating system. Most applications only need an operating system that is "good enough" to meet certain requirements. In most situations, given all the features these applications require, Windows NT is probably the best system available for most of these tasks.

Common Uses of Real-Time Systems
The common usage, loose-terminology definition of "real time" is used to refer to any system that modifies an industrial process based on measurements from that process. Many industrial processes such as job shop flow (controlling the flow of work through the factory) and inventory control are often lumped together into the "real time" category.

Feature  Benefit  
Real-time priority class Application priority can be defined for high levels of responsiveness.
Virtual page locking into RAM Avoids paging while doing real-time work to improve predictability of response time.
Deferred procedure call (DPC) Limits work done at the interrupt level and results in improved interrupt latency. The interrupt schedules a DPC, but does not process it immediately. This permits other interrupts to proceed.
Interrupt masks Disables all interrupts at equal or lower priorities to ensure that the latency of interrupts at higher priorities are not interfered with.

Sometimes, the term "real time" refers to a 4kb operating system that creates and schedules primitive tasks by absolute priority, responds immediately to hardware interrupts, and does very little else. This is a useful definition for simple applications that gather instrumentation signals or control industrial processes.

This description is still often appropriate. However, a personal computer can be equipped with sophisticated adapter boards with CPU and memory, instead of just data registers. Incoming data can be buffered on the physical adapter, which enables general-purpose operating systems to do what the special purpose real-time systems did previously. Several features make Windows NT an extremely good general-purpose operating system for real-time applications.

Within the Microsoft Windows® family, two initiatives focus on real-time activities. Within the financial services market, where financial analysts and traders often need to know about pricing and market movements almost instantaneously, Microsoft has put together an initiative referred to as OLE for Real-Time Market Data. This initiative is designed to provide a standard way for financial professionals to get access to real-time financial data.

For scientific and manufacturing users, Microsoft has been working with a number of applications and device manufacturers to define a set of Windows-based interfaces that data acquisition equipment can tie into easily. This effort is referred to as Windows for Science, Engineering and Manufacturing, or WINSEM.

Real-Time Systems and Windows NT
Windows NT has been designed from the ground up to be a highly responsive, general-purpose operating system. To the real-time developer, this implies that there are some areas where Windows NT will not be suitable for real-time applications as a result of basic design choices made in its architecture. Topics of interest in real-time systems include:

Responding to external events

Priorities and scheduling

Synchronization requirements

Deterministic response times
Paradoxically, many design choices made within Windows NT actually result in a high level of responsiveness. This article will discuss these important real-time topics in terms of the capabilities offered by Windows NT. For reference, a section later in this article will provide a high-level discussion of the Windows NT architecture.

Responding to External Events
Real-time applications are designed to respond to external events within a specified time interval. Windows NT offers strong capabilities in the areas of both interrupt management and input/output (I/O) management.

Real-time applications use interrupts to ensure that external events are noticed by the operating system. It is critical that interrupts be handled promptly, according to their relative priority.

Within Windows NT, the kernel and the hardware abstraction layer (HAL) are tuned to optimize interrupt delivery and event dispatching. The kernel provides interrupt dispatching to the rest of the system. The kernel can operate at one of 32 possible interrupt levels, as shown in the table below. These levels help prioritize the tasks that must be accomplished before other, less time-critical work. The kernel reserves eight interrupt levels for its own use. The remaining 24 interrupt levels are mapped onto hardware interrupts with the HAL.

Interrupt Level(s) Definition
31 Hardware error interrupt
30 Powerfail interrupt
29 Interprocessor interrupt
28 Clock interrupt
12–27 These levels map to the traditional interrupt levels 0–15 used in PCs
4–11 These levels are not generally used
3 Software debugger interrupt
0-2 Reserved for software-only interrupts to prioritize work within device drivers and executive components

Windows NT handles interrupts on a preemptive basis. When an interrupt occurs, all execution at lower interrupt levels is suspended and execution begins immediately on the highest-level request. Processing continues until the highest-level process has been completed. This places a responsibility on device drivers in that system responsiveness is directly related to how quickly a device driver exits its interrupt routine.

In other words, Windows NT offers applications a multilevel interrupt mask. Higher priority interrupts can occur when the interrupt mask allows them to occur. Changing the interrupt mask raises the level so that lower-level interrupts cannot use system resources until the handling routing for the higher-level interrupt has been completed.

Multiprocessor systems
Windows NT is designed for multiprocessor systems. When an interrupt is dispatched, the kernel dispatches the interrupt to just one of the processors in the system. All other processors continue executing uninterrupted. Interrupts can be handled on any of the processors in a computer; this allows interrupts to be handled by idle processors, rather than concentrating the load on a single processor. For these reasons, multiprocessor systems can offer significant benefits for real-time applications.

Asynchronous I/O
Asynchronous I/O is a very powerful mechanism for user-level, real-time applications; the application can queue I/O and continue processing without having to either wait or respond immediately to some end-of-I/O event. Additionally, there are completion mechanisms in the I/O system (completion port I/O) that efficiently use the kernel synchronization and executive scheduling capabilities to distribute I/O completion processing to the most recently busy thread. This assures that cache is not invalidated and that the system makes efficient use of the processing power available. Asynchronous I/O not only results in enormous dividends for multiprocessor systems—it does not require any appreciable overhead on single-processor systems.

In many cases (such as in a Win32® application), asynchronous I/O may not be important and the application will wait for the I/O to complete before returning. However, when the user (or kernel component) wants to work while the asynchronous I/O is completing, that user can specify that he or she doesn't want to wait for the request to complete, and can continue working in the rest of the application. When the asynchronous I/O eventually completes, an event or some other notification mechanism will fire. The application can check for this completion event at a convenient time in the future.

Device drivers
Device drivers are very important to real-time users of Windows NT. In particular, processing in a device driver will proceed to completion without any interruptions, which is a feature that many real-time applications want. In order to get this kind of performance, however, the device driver code must be extremely solid. Windows NT device drivers run entirely within the system process and have access to all hardware through the HAL. A typical device driver will have several components, as described in the following table.

Component  Description
Initialization routine This routine initializes hardware and sets up data structures used by the driver at startup time.
Interrupt service routine (ISR) This routine handles an interrupt on the device that the device driver controls.
Deferred processing call (DPC) One or more DPCs handle non–time-critical processing for the driver.
System thread Some, but not all, drivers will have a system thread for very low- priority work.

When a device driver starts, the initialization routine will typically make the driver known to the system, register some entry points, and register an ISR. The device driver will wait, consuming only memory resources, until an interrupt occurs that meets the criteria of the driver's ISR; the driver's ISR is then entered. The driver will not be interrupted until the end of its interrupt service routine, unless a higher level-interrupt occurs. Unlike other operating systems, an ISR on Windows NT can be interrupted by another ISR with higher priority; this is one reason why interrupt latency is hard to define for Windows NT.

When a driver is in its interrupt service routine, it should perform the minimum processing necessary to handle the interrupt, save the state necessary for processing the interrupt, queue a DPC routine for later processing that is not time-critical, and return. The DPC will occur at some later time—although it may occur immediately after leaving the interrupt service routine, if the system is not very busy. A DPC will run to the exclusion of all other processing (other than ISRs) until it exits. Most device driver processing is accomplished in this deferred processing routine or in even lower-priority routines queued by the DPC. Several important rules apply to DPCs. The most important rule is that a DPC cannot wait or lock up the system. Another important rule is that the DPC must have all the memory it accesses locked down in physical memory, so that it cannot incur page faults.

It should be possible, using the support routines and driver model provided by Windows NT, to write device drivers that handle even the most complex and high-speed data acquisition hardware.

Priorities and Scheduling
Real-time applications, by definition, have a time component associated with their behavior. In this context, it is important to understand how Windows NT assigns priorities to applications and schedules their execution. This section will also discuss several other elements of the operating system and how they can affect real-time applications.

Process priority
Within Windows NT, user applications are defined as processes. Windows NT is a preemptive, operating system that allows multiple processes (applications) to run at the same time. A process has a number of properties associated with it. For real-time applications, one of the most important properties is the priority class (such as real_time) that defines the basic priority at which the application will run. The priority model within Windows NT includes 32 priority levels, of which 16 are reserved for the operating system and real-time processes. Note that priority levels are different from the dispatch interrupt levels discussed in the kernel section. User applications almost always run at interrupt level 0, regardless of the priority level they are set to.

Each process maintains a private address space to ensure that it will not interfere with other processes, and each process has a base priority class. As shown in Figure 1 below, real-time applications can run with a base priority class of 31 (highest priority), 24, and 16. Typically, real-time processes will run at priority 24. Other applications (dynamic classes) have a base priority class of 15, 13, 9 (normal foreground process), 7, 4, 1, and 0.

Figure 1. Windows NT priority classes

Each process also has one or more threads associated with it, within the same address space, where each thread represents an independent portion of that process. The number of threads is limited only by the available memory and resources. The properties associated with each process, including the priority level, are inherited by these threads.

Each thread has a current priority derived from the process' priority class. By using an application programming interface (API) call that varies up or down from the process' base priority, you can vary the current priority up or down within defined limits. For example, a process running at real_time class 24 can have threads that run anywhere between classes 26-22, depending on their own independent priority. These threads will always stay within the real_time priority class.

Threads are independently scheduled by the executive. Associated with the process is a quantum (the maximum amount of time a thread can execute before the system checks to see if other threads with the same priority want to execute). In general, real-time processes will have priority over almost all other activities or system events. However, for processes in the spectrum of dynamic classes that are running at lower priority levels, a number of events within the system, such as I/O completion, could cause a temporary priority boost for a thread, giving it priority within a process.

Finally, there is a single system process, within which there can be multiple system threads running. This system process runs all device drivers, the kernel, the executive, and device drivers. All these components share a single address space, known as the system space. A device driver, executive component, or the kernel can create a new system thread at any time—these threads can be used to do work in the context of the system process. The technique of running a thread within the context of the system, where it has direct access through the HAL to device hardware, might be of interest to real-time engineers.

Memory management
Memory management is another area in which many real-time engineers are interested. Windows NT is built around a virtual memory system. For real-time applications, Windows NT solves many of the problems that face real-time developers using more traditional virtual memory systems. First, paging I/O occurs at a lower priority level than the real-time priority process levels. Paging within the real-time process is still free to occur, but this really ensures that background virtual memory management won't interfere with processing at real-time priorities.

Second, Windows NT permits an application to lock itself into memory so that it is not affected by paging within its own process. This allows even very large processes (such as raster image processing, where some processes are over 100MB) to lock all their memory down into physical memory and avoid the overhead of paging, while allowing the rest of the system to function normally.

Finally, Windows NT memory management allows for memory mapping, which permits multiple processes—even device drivers and user applications—to share the same physical memory. This results in very fast data transfers between cooperating processes or between a driver and an application. Memory mapping can be used to dramatically enhance real-time performance.

Cache management
Cache management is one of the drawbacks of using a general-purpose operating system such as Windows NT for real-time applications. Memory caching is a technique that uses a small amount of high-speed memory to hold the most recently used code or data. If the next instruction or piece of data is not in the cache, the CPU retrieves it from the slower main memory. Using a cache results in the best average system performance for an operating system, but it does introduce an element of unpredictable timing in real-time environments.

Synchronization Requirements
One of the most difficult tasks of real-time systems is ensuring that different threads and processes stay synchronized. That is, within a real-time application, the timing at which different activities occur is important. For example, if one part of the application completes before a second part gets the most current data, then the process that the application is monitoring may become unstable. Synchronization results from ensuring that application components are prioritized properly.

Kernel synchronization
Most of the work in the kernel is performed at the highest software interrupt level (known as dispatch_level) or above. The kernel's job primarily consists of synchronizing execution on multiple processors, dispatching, and system database maintenance; it does very little work that is not a direct consequence of a request by a user or subsystem.

The kernel also has a rich set of dispatch objects. These objects synchronize execution within device drivers and Windows NT executive components. Included in this set of dispatch objects are various timers, events, mutexes, and semaphores. These objects can be used in a number of ways to synchronize execution as necessary within the Windows NT executive and kernel. They are also used by subsystems to implement the synchronization primitives exported to user applications.

With general-purpose operating systems that use virtual memory and caching algorithms, it is often difficult to ensure that events will take place within specified periods of time. Windows NT offers several timers that can be used to obtain more deterministic time intervals for managing events in real-time environments. These timers generate software interrupts from the kernel.

Windows NT Workstation version 3.5 makes it possible for applications to use the basic system timer with the GetTickCount( ) API. The resolution of this timer is 10 milliseconds. Several CPUs support a high-resolution counter that can be used to get very granular resolution. The Win32 QueryPerformanceCounter( ) API returns the resolution of a high-resolution performance counter. For Intel®-based CPUs, the resolution is about 0.8 microseconds. For MIPS®-based CPUs, the resolution is about twice the clock speed of the processor. You need to call QueryPerformanceFrequency( ) to get the frequency of the high-resolution performance counter.

Another method that ensures proper synchronization is a spinlock. A spinlock is a locking mechanism associated with a global data structure; this mechanism ensures that only one thread can get access to the data structure at any given time. When the first thread is done, it releases the spinlock so that other threads can get access to the data structure. Within Windows NT, spinlocks are often used by device drivers to ensure that device registers or other data structures can be accessed by only one device driver at a time. Real-time applications can use spinlocks to synchronize timing events during an interrupt response or another similar activity.

Deterministic Response Times
With real-time systems, it is important to understand how quickly the operating system can respond to external events. The more deterministic the operating system, the more suitable that system will be for real-time applications.

To process an interrupt, three steps are generally taken:

The first step involves the hardware interrupt latency. This represents the time that it takes for the CPU to finish processing the current instruction, flush the instruction pipeline, read the interrupt vector, locate the address of the Windows NT trap handler, and jump to that address.

Second, the trap handler records the current computer state and creates a trap frame that records the execution state of the thread that was interrupted, including program counters, registers, and other information. At this point, the trap handler starts an interrupt dispatcher that determines the source of the interrupt. This dispatcher then transfers control to an external routine, called an interrupt service routine (ISR), or to an internal kernel routine. The ISR is provided by the device driver for the particular device that caused the interrupt.

Finally, at this point, the ISR starts an I/O transfer to or from the device, and executes other threads while the device completes the transfer. When the transfer is complete, the device again interrupts the CPU for service.
Frequently, in real-time environments, latency refers to the total time that it takes for these steps to occur—that is, the amount of time that it takes for the CPU to acknowledge and handle an interrupt.

Sample measurements
In Design of a TCP/IP Router Using Windows NT, a paper delivered at the 1995 Digital Communications Design Conference, the ability for Windows NT to handle real-time activities was measured. (The paper's author, Brian Catlin, is a principal at Catlin & Associates, a systems analysis and programming firm in Redondo Beach, CA.)

The measurements described in Catlin's paper were taken to analyze the appropriateness of using Windows NT as a platform for a transmission control protocol/Internet protocol (TCP/IP) router. The system being measured was a Hewlett-Packard® XU 5/90 personal computer with one 90 MHz Pentium CPU, 256kb synchronous cache, 16 MB memory and 540 MB of disk space. The measurement test equipment included various Hewlett-Packard systems.

The paper concluded that Windows NT was appropriate for use as a real-time system. The basic measurementsreported in the paper are listed in the table below. The primary discrepancy in the overall duration of the event was attributed to the effects of virtual memory and, in particular, the cache manager.

Measurement  Duration
Hardware interrupt latency 1.8 – 2.9 microseconds
Interrupt dispatching 4.6 – 10.5 microseconds
Interrupt service routine length 10.3 – 16.7 microseconds
Total elapsed time 16.7 – 30.1 microseconds

Windows NT Operating System Overview
The Windows NT operating system is based on a design principle often referred to as a microkernel architecture. To ensure higher levels of performance, the design time for Windows NT modified the microkernel design by eliminating the clearly defined break between the kernel code and other system components. In most cases, this distinction is not significant and users get the benefit of a microkernel design with better performance.

The basic architecture of Windows NT uses a layered design composed of a number of components that are working in concert to provide the basic services that a user or application needs to accomplish its tasks. Working from the inside out, these components include the kernel, hardware abstraction layer, executive, device drivers, and environment subsystems. Figure 2 (below) displays an architectural diagram of Windows NT.

Figure 2. Windows NT system architecture

The Kernel
The kernel is the core of the Windows NT operating system. It is a dispatcher, not a scheduler, and is responsible for handling events within the system. Note that this process is very complex and it is difficult to characterize specific performance numbers for interrupt delivery time or dispatch timing. The Windows NT kernel is fairly lightweight—it performs a limited set of functions efficiently, thereby freeing CPU cycles for other processing. These functions would be of little interest to a traditional application program; for instance, the kernel neither knows nor cares about file I/O. Still, the primitives offered by the kernel are the foundation of the operating system services used by applications.

Hardware Abstraction Layer (HAL)
Windows NT is designed to run with a variety of CPUs and hardware platforms. This places a heavy burden on the kernel to efficiently reconcile kernel processing with the need to handle interrupts, cache management, memory handling, register assignments, and other hardware-specific implementations. To solve this portability issue, Windows NT isolates the kernel code from the hardware by using an isolation layer referred to as the hardware abstraction layer, or HAL. The HAL presents a "virtual machine" to the kernel, executive, and device drivers. It maps this virtual machine onto the underlying hardware in an efficient manner and eliminates the need for Windows NT to provide hardware specific kernels, which improves overall efficiency. The HAL presents a single mechanism for device driver and kernel components to use on any hardware platform.

As an example, in Intel®-based systems, device drivers use the INP and OUTP instructions to access the I/O port registers directly. Other CPU architectures use different mechanisms for accessing device I/O registers. Windows NT resolves this difference with macros (such as read_port_uchar and write_port_uchar) that take the appropriate action for each supported CPU.

The Windows NT Executive
The Windows NT executive provides services that allow the operating system to perform operations that may span various systems or managers and kernel operations. It provides services to user applications, subsystems, and some device drivers. The executive includes many systems and managers, each of which fulfills a particular function. In traditional mini-computer operating systems, these services are known as system services. In Windows NT, major systems include the cache manager, security monitor, object manager, network access, and other functions. The I/O management and process management routines are probably of most interest to real-time engineers.

The I/O system has a rich set of I/O operations that are exported to other components. These operations range all the way from traditional, synchronous buffered read-and-write operations up to high-speed, buffer-mapped asynchronous I/O operations. Except for creation of the I/O channel itself, all internal I/O operations in Windows NT are asynchronous—that is, they are not expected to be complete upon return from the I/O operation request. This is a major break from mainstream operating systems, and is a major reason for the responsiveness of Windows NT to user inputs and interrupts.

A Brief Summary
To summarize several important concepts mentioned earlier in this article (in the "Process priority" section), Windows NT lets multiple processes (user applications) run within the system at the same time. Each process is associated with one or more threads, where each thread represents an independent portion of that process. Threads are independently scheduled by the executive based on their priority. A single system process runs all device drivers, the kernel, the executive, and device drivers—components that share a single address, or "system" space. A thread can be run within the context of the system process, where it has direct access through the HAL to device hardware.

More About Device Drivers
Device drivers in Windows NT are kernel-level code that extend the capabilities of the kernel and executive to control new devices or, in some cases such as file systems, to provide new services to user-level components. Generally, these services are very constrained and consist of nothing more than the ability to use a new device of an already supported kind. However, device drivers for totally new types of devices can be written and integrated into the system. Windows NT also has a rich set of direct memory access (DMA) handling support routines. These routines support conventional DMA, as well as scatter-gather DMA.

Environment Subsystems
Subsystems in Window NT are used to provide user environments for applications. Examples of Windows NT subsystems are the Windows 32 subsystem and the POSIX subsystem. Each of these subsystems provides a set of primitives specific to its user environment. The primitives are built upon the primitives provided by the Windows NT executive and kernel.

Common Questions
Q. What kind of interrupt latency does Windows NT provide?

A. Interrupt latency is a function of the drivers that are running and what they do at interrupt time. The Windows NT design philosophy encourages drivers to do as little work as possible. The kernel architecture generally lets a driver do a very small amount of work at interrupt time and use a deferred procedure call (DPC) for driver-related processing at a lower interrupt request level (IRQL). This design allows for very short interrupt service routines and results in reduced interrupt latency.

Q. Can the kernel respond to an interrupt while actually executing kernel code?

A. Yes, although there are some spots where the IRQL level is raised or where interrupts are disabled. In general, the kernel is not preemptible, but interrupts can and do happen during execution of the kernel. The rules for interrupts are very similar to other systems. Windows NT has a multilevel interrupt mask. Higher-priority interrupts can occur when the mask allows them to occur. Changing the mask raises the level where lower-level interrupts cannot occur.

Q. Does Windows NT have a fixed priority scheduler?

A. Windows NT supports 32 priority levels that can be assigned to particular threads. Sixteen of these priority levels are variable; that is, the scheduler adjusts your priority up and down as events occur. Sixteen levels are fixed priority, or "real-time," which means that the operating system cannot adjust the priority level. The Win32 API allows access to both the variable and fixed priority classes and to most of the 16 priorities in each level.

Q. Does Windows NT support asynchronous I/O?

A. Yes. Windows NT provides three different completion notification mechanisms, which allows for a very flexible approach to using asynchronous I/O.

Q. Does Windows NT wait for a clock tick before it responds to an interrupt?

A. Assuming that interrupts are not disabled or masked at that level, the system handles the interrupt immediately.

Q. Does Windows NT support a real-time or contiguous file system?

A. With file systems, the bulk of the performance cost occurs when a file needs to grow. With NTFS, Windows NT can preallocate space to files, although it is not strictly contiguous. The RAW file system provides unstructured storage on an unformatted disk volume, so that the application itself can control the contents of the file system.

Q. Does Windows NT support memory locking?

A. Windows NT allows an application to control the size of its working set. An application can lock memory into its working set.

Q. Does Windows NT support direct I/O and memory access?

A. In general, Windows NT does not allow an application direct access to I/O ports. If this is needed, a driver needs to be written.

For More Information
Catlin, Brian. Design of a TCP/IP Router Using Windows NT. Presented at the 1995 Digital Communications Design Conference. Redondo Beach, CA: Catlin & Associates.

Custer, Helen. Inside Windows NT. Redmond, WA: Microsoft Press, 1993.

The answer is you can't do this from an MFC program.  Windows is NOT a real-time operating system (RTOS) in spite of the misleading run-time priorities.  These are for future use in the event that someday Windows supports real-time.

The only solution for your problem under WinNT is to write a device driver which "grabs" the CPU and doesn't let go until the I/O operation is finished.  A user program cannot do this as NT will preempt it.  A device driver, however, can.

Another approach is to solve this problem in hardware.  If you are desiging your own I/O board, add some smarts to it and a buffer to capture the data and hold it until Windows gets around to getting it all.

You might also consider using a real RTOS.  There are several out there.  QNX is one choice for something like this.
dylanlemonAuthor Commented:

Is that to say that all of the data acquisition software in the world that runs under win95 gets interrupted on the millisecond timescale?  There's a lot of people writing software for win95, ARE YOU SURE ABOUT THAT?  How do you know?

I accept that your answer is educated, and logical, but without proof or better reference other than trusting your word, I have to temporarily reject the answer, with all due respect.

Is there nothing else I can do in Win95?  The issue is time and therefore money.  We need a cheap, immediate solution to upgrading the student labs to something the students know how to use, ie windows.

Is there a way to increase the priority of the class or thread to some higher level that may help?  But, not necessarily real time?  ie, how good can I make it?

Cloud Class® Course: SQL Server Core 2016

This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.

dylanlemonAuthor Commented:

Yes, I accept.  It may be good enough to get NT on those machines, will look into it.

But, another option has been proposed.  There are several LINUX experts walking about the halls here, and they speak of a real time port to LINUX.  There are already two experiments in the lab using LINUX without the RT port.  

Do you have any knowledge of this RT port?

I will test the modified MTRECALC example in NT, and see if I get the high priority thread.  I should not expect complete dedication of the cpu, but some improvement, correct?  I will review these notes if I do actually use NT, Thank You.  
I understand that there is an RTOS kernel that runs under linux and will get you where you want to go.  

You can get a realtime task to have almost 100% CPU time under NT and Win9x.  Usually this will get your IO working for short periods of time.  The problem is that you can't stay in this mode for long as everything else stops.  
dylanlemonAuthor Commented:
You can get a realtime task to have almost 100% CPU time under NT
     and Win9x.  Usually this will get your IO working for short periods of
     time.  The problem is that you can't stay in this mode for long as
     everything else stops.  

OK!!, how do I do that?>??? specifically under Win9x?

almost might be good enough, after all, we're only dealing with millisecs here, specifically 1024 samps over about 10ms.
The best way to do it under Win9x is to use a 16-bit DLL or application or a VxD.  They are not preempted by Windows and can HOG 100% of the system forever.  This is most commonly called a system hang when it happens when you don't want it to.
dylanlemonAuthor Commented:

Ah yes. Luckily I have written a separate dll in c ready made for this task.  The only thing to do is to compile it to 16bit.  There's a compiler flag isn't there...  
Depends on what compiler you're using.  If it's MS VC++, you are out of luck.  MS doesn't support 16-bit since VC++ 4.0.  You can still get Symantec C++ and Borland C++ which still have 16-bit capabilities.
dylanlemonAuthor Commented:

I'm covered I think, the only question is compiling to dll.  I've long lost my old 16bit cd rom with 4.0, and it's just a question of either finding that, or using the disks I've recovered from the lab for ms c, but they're old, I've never used them, and I'm concerned about the compilation.

In any case, thanks for all your help today, I'll make some progress and let you know when I sort it all out.

dylanlemonAuthor Commented:

Well, now I've compiled the simple c code to a 16bit dll, but LoadLibrary() in MFC does not load the library.  

  libName = "driverdll";  // the driver's file name
  hLib = LoadLibrary(libName);

    //the above condition ends up true!
    pTextLine->SetText("unable to load driver DLL"); //unable to load DLL

In the dll, a simple c code, I've used _far _export on each procedure I want to load using GetProcAddress(), but I dont even get that far because the library wont even load with LoadLibrary.  

So, what am I doing wrong?

I compiled the c code with Borland 5.02 on Win NT to 16bit dll, and the MFC app with V C++ 4.0 believe it or not, in Win 95.

I'm going to post this as a new question, just so you'll get the points.  Not that you need them, I've looked into your history a bit.  Impressive...

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.