发信人: bigapple (红富士), 信区: NTM
标  题: NT for Soft Real-time Control(Design)
发信站: 哈工大紫丁香 (Tue Jul 25 11:12:57 2000) , 转信


Design of the Windows NT Operating System

 When we first started to evaluate the Windows NT operating system for soft co
ntrol applications, we were concerned about several key design areas in additi
on to the determinism of the operating system.  Foremost in our minds was safe
ty, so system integrity features were key including rapid failure detection an
d proper kernel exception handling.  In addition, we wanted to make sure stand
ard PC peripherals used in conjunction with I/O scanner and industrial network
 adapters could be mixed and matched with minimal risk of interoperability pro
blems.  Other areas of concern included the efficiency of thread synchronizati
on primitives, and the ease in which we could avoid potential priority inversi
on problems associated with synchronization objects.
 In this section, we will discuss our investigations into these design areas, 
and we will also discuss some other key strengths of the design of the Windows
 NT operating system that have not been previously available in other control 
systems but are very desirable from a soft control perspective. We start with 
a discussion of unexpected kernel exception handling and the blue screen.

Understanding the Blue Screen of the Windows NT Operating System

 There seems to be a great deal of misunderstanding regarding the stability of
 the Windows NT operating system and the meaning of the ¨blue screen.〃  Befo
re we discuss the blue screen in detail, we need to review the topic of unexpe
cted kernel exceptions and their causes.
 When executing, the Pentium processor generates several self-diagnostic fault
 and abort exceptions.  When an exception is thrown, execution can be restarte
d if an exception handler exists that considers it acceptable to restart the f
ault.  However, execution stops on all abort exceptions.  The most relevant fa
ult and abort exceptions that are likely to be encountered in a control system
 are due to either a hardware failure or a software defect.  The most common e
xceptions are summarized in the following table:
 0  Divide Error. DIV of IDIV divide by zero  fault
 2  NMI exception. Hardware error  abort
 5  Bounds Check Array access. Bounds check failed  fault
 6  Invalid Opcode.  Misaligned or corrupt code  fault
 8  Double Fault Exception occurred while dispatching an exception  fault
 10  Invalid TSS. An external interrupt attempted a task switch via an invalid
 TSS  fault
 12  Stack Exception. Stack segment overflow or underflow  fault
 13  General Protection.  Attempt to access memory that is protected or invali
d  fault
 14  Page Fault. Attempt to access a virtual page that is not loaded  fault
 16  Floating Point Error. Floating point calculation exception  fault
 
 In response to any fault exceptions at ring 0, the exception dispatcher of th
e Windows NT operating system makes special checks to determine whether the pr
ocessor was operating on the interrupt stack and whether the IRQL level was at
 or above the level for DPC processing.  If these two conditions are true, eit
her system code or a device driver was executing, so the exception is consider
ed fatal, and the system halts all threads, bug checks, and then halts or rest
arts.  The bug check can be set up to: 
刋 do nothing 
刋 generate a blue screen syndrome dump 
刋 create a memory dump file 
刋 enter the kernel debugger 
 Reviewing the above list, you can see that all these exceptions were caused b
y either a hardware failure (memory parity error for example), or some privile
ged code corrupting kernel memory or executing a critical bug with unknown con
sequences.  The errant code may not have excepted until after it corrupted wri
table parts of ring 0 memory (including the control and status registers of I/
O and control devices).  What is known for certain is that code has failed.  A
s a result, the only safe thing to do is fault the processor and put the I/O i
n a fail-safe condition as soon as possible.  
 In both the control and the data processing world, continuing after an unexpe
cted kernel exception, though typically uneventful, is potentially unsafe.  Th
is is true for not only Windows NT operating systems, but for other operating 
systems, real-time operating systems, and controller executives.  By halting t
he processor immediately, and letting the I/O scanner watchdog time out, the W
indows NT operating system responds appropriately to the kernel exception. The
 blue screen of the Windows NT operating system is simply the equivalent of th
e PLC-5 red-light fault.
 Some extension technology vendors of the Windows NT operating system claim th
at they can partition memory in such a way as to guarantee that their real-tim
e executive safely continues to run after an unexpected kernel exception occur
s.  We feel that this is a disadvantageous design and a potentially unsafe thi
ng to do in response to a exception, for the following reasons:
刋 The system is just as likely (if not much more likely, see next item) to generate an unexpected kernel exception in the context of the real-time executive.  
刋 To properly assure fail-safe operation, the real-time executive should halt immediately, just as the Windows NT operating system should halt.  
刋 No shutdown handler can be safely called from this state, and even if one was, it could not be relied on to recover from corruption, interrupt stack overflow or from a NMI.  Consequently, the I/O scanner adapter must be relied on to guarantee a watchdog time out and set the I/O to its fail-safe state.  
刋 Having multiple system failure modes simply increases system complexity and makes system integrity testing much more complex.
The likelihood of encountering operating system and device driver bugs is high
er in systems that are either more complex or have undergone less testing.  Th
ough the Windows NT operating system is more complex than the proposed real-ti
me executives it has undergone extensive testing.  The lowest-volume, least-te
sted components of a soft control system, which are the most likely components
 to be the cause of kernel exceptions, are actually the I/O adapter scanner dr
ivers.  In these partitioned systems, these drivers are part of the real-time 
executive and it is likely that the real-time executive will encounter unexpec
ted kernel exceptions than the Windows NT operating system.
When using premium systems from the highest quality hardware OEMs (Compaq劌, D
EC劌, Dell劌, Hewlitt-Packard劌, IBM劌, Rockwell Automation, etc.), Windows NT
 operating systems have proven to be extremely reliable. The kernels and drive
rs endorsed by these key OEMs are virtually bug free.  Actual case studies sho
w that reliability problems correspond to its use with immature components and
 device drivers.  For example, having to modify your systemˇs BIOS in order t
o run the Windows NT operating system could be an indication that the manufact
urer has not performed adequate testing. 
It is our opinion that a conservative upgrader of Windows NT operating systems
, using a premium OEM platform, will find a Windows NT operating system more r
eliable than a real-time executive running in conjunction with a Windows NT op
erating system on the same box.  The use of rigorously tested, high-quality ha
rdware is an obvious requirement for any PC-based control system.
Regardless of memory partitioning, kernel objects within the Windows NT operat
ing system always have access to most of the physical memory used to memory ma
p dual-ported RAM into the system, and they also have access to the hardware I
/O ports.  The presence of a kernel exception indicates that code has executed
 that either contained bugs or encountered an unanticipated state due to a har
dware failure.  The code that contained bugs did not necessarily except immedi
ately, and it may have corrupted the states of devices or system control struc
tures in ways. This would make it unsafe to continue even for the partitioned 
real-time executive.

Interoperability/Ease of Tuning vs. Real-time Performance Features

The need for easy and trouble-free integration of third-party hardware is anot
her key design issue that is critical to the successful implementation of open
 control.  At the same time, it would be nice if the platform could support so
me more exotic means of achieving better real-time performance.  As we have al
ready discussed, the Windows NT operating system defines a set of standard dri
ver rules that were selected to verify interoperability and performance. Drive
rs are encouraged to have as short an interrupt service routine (ISR) as possi
ble, and to be able to tolerate fairly long delays in Deferred Procedure Call 
(DPC) processing.  
If a driver obeys these rules, and the many other rules associated with plug a
nd play (PnP) configuration, a driver most likely coexist well with other driv
ers conforming to these rules.  This is a primary feature of ¨open〃 control:
 trouble- free mixing and matching of hardware options.  Unfortunately, this t
rouble-free operation comes at a price when pushing real-time performance to i
ts limits.
Critics of the real-time performance of the Windows NT operating system have r
epeatedly raised several issues in which they have asked for many real-time de
sign extensions.  Most of these extensions would cause severe tradeoffs with o
ther goals of the Windows NT operating system including ease of tuning, and tr
ouble-free driver operation.  
The following list summarizes some of the criticisms that have been voiced and
 the changes that have been recommended:

Threads are always lower priority than ISRs and DPCs Many of the APIs of the W
indows NT operating system are simply not allowed to be called at elevated IRQ
Ls since they cannot use kernel objects for synchronization.  If application t
hreads were allowed to operate at an elevated IRQL, they would have to follow 
the same rules as ISRs and DPCs.  Since the only source of time-critical event
s is system interrupts and timers, the same functionality could be accomplishe
d in an ISR or DPC.  Though this might be a more convenient programming model 
than ISRs and timer DPCs, it really wouldnˇt improve performance significantl
y. 

DPCs are processed in a FIFO queue without prioritization The problem here is 
who would assign the priorities, and the second problem is that high- priority
, recurring DPCs could badly delay low-priority DPCs without even knowing what
 their purpose was.  To make such a capability useful, end-users would have to
 be able to adjust these priorities and ease of tuning would be lost. How is a
 driver to know its priority relative to a set of unknown peer drivers?  The W
indows NT operating system chose a FIFO to make sure each driver has access to
 the queue.

DPCs are always lower priority than interrupts DPCs were created to complete t
he processing of an interrupt or to be timer routines.  If an ISR needs to per
form its DPC action at an elevated IRQL, it should have done it in the ISR.  P
lacing it in a DPC that  blocks interrupts is no different than extending the 
ISR.

The Windows NT operating system assumes DPC timer routines are less time-criti
cal than interrupts.  It might be useful to have a timer routine that had an a
ssociated IRQL level other than that of DPCs to allow extremely deterministic 
polling drivers. However, from the perspective of the Windows NT operating sys
tem, timer routines are usually used to timeout I/O requests and to poll devic
es to see if operations are complete.  It might be desirable to be able to spe
cify a timer interrupt routine and associate an IRQL with it. However, not hav
ing this feature is certainly not a showstopper.
WaitForObject is FIFO rather than prioritized-FIFO, and synchronization object
s do not support automatic priority boosting to prevent priority inversion The
se features would make sure that high-priority threads are not impeded by lowe
r-priority ones when using simple synchronization objects, such as mutual excl
usion semaphores (Mutex Objects), and critical sections.
If WaitForObject was prioritized, high-priority threads could skip forward in 
line and minimize the wait times for accessing synchronization objects.  In ad
dition, if the threads, which owned synchronization objects, were automaticall
y boosted to the priority of their highest waiting thread, the priority invers
ion for simple synchronization objects would not be a problem.
However, these concepts do not make sense in the context of the dynamic priori
ty boosting heuristics of the Windows NT operating system. Since synchronizati
on objects are used independently of certain threadsˇ priority classes, this 
would introduce confusion and complexity into the thread dispatcher.  Furtherm
ore, these features would introduce a significant amount of overhead into the 
operations of the dispatcher.  Since even real-time thread priorities are modi
fiable at run-time, supporting these concepts would introduce a great deal of 
complexity into the process services APIs.
Alternatively, applications can easily work around these problems by creating 
slightly more complex synchronization objects, built off of the primitives, at
 the cost of a moderate hit in lock performance.  Encapsulation classes can be
 (and have been) created that provide priority inversion protection and priori
tized waiting.  Still, developers have to be careful of hidden locks, which mi
ght be used to provide synchronization from within runtime libraries. 

System Scalability and Portability

One area where design of the Windows NT operating system is a perfect fit for 
soft control is the area of system scalability and portability.  A Windows NT 
operating system supports increases in processor power from low-end Pentium sy
stems up to the Pentium Pro and to dual- and quad-multiprocessor systems. Pent
ium II processors, with clock speeds ranging from 333MHz to 450MHz are on the 
near-term horizon. CPU performance can already be scaled up by a factor of rou
ghly 8, without any changes in software design. The Pentium II should double t
hat high-end over the next year or two. The symmetrical multiprocessing (SMP) 
design takes advantage of application threads and provides excellent performan
ce improvements.  In addition, Windows NT operating systems support multiple C
PU architectures. Ring 3 application code is highly portable between x86 and A
lpha.  Drivers require slightly more attention, but even drivers in the Window
s NT operating system can be written in C and have a high degree of CPU portab
ility.

Standard Drivers and Ease of Administration

Another key design advantage of using a Windows NT operating system is the abi
lity to directly leverage standard drivers and new plug and play standards.  I
n addition to I/O scanners and industrial networks, soft controllers need to i
nteract with TCP/IP networks, serial ports, SCSI ports, and possibly in the ne
ar future, USB and FireWire devices.  Threads have full access to all the stan
dard Microsoft drivers. Inter-driver access, class driver and mini-port archit
ectures of the Windows NT operating system simplify the support of many device
 types, but only if you are using a standard Windows NT operating system.
In addition, Microsoft is making device management even simpler with the new e
xtensions being added to the Windows NT 5.0 operating system as it leverages M
icrosoftˇs second generation of plug and play.  Microsoftˇs automatic device
 driver configuration system and the rules for well-behaved drivers provide an
 excellent framework for maintainable and interoperable open control.

Summary

Handling of unexpected exceptions by the Windows NT operating system, typified
 by the blue screen display, was found to be acceptable for soft control appli
cations.  The handler unified many system failure modes and immediately stoppe
d control thread processing, so that the I/O scanner watchdogs could quickly d
etect system failure and place the I/O in its fail-safe state.  
Though the Windows NT operating system precluded some advanced techniques for 
improving real-time performance in its device drivers, most of these technique
s would have introduced the need for critical user tuning and administration, 
vastly reducing the ease of integrating hardware and software from different v
endors.  The design of the Windows NT operating system provided high levels of
 performance, while maintaining strong rules for device interoperability. 
The advanced features of the Windows NT operating system provide outstanding s
calability, portability, and ease of administration. The Windows NT operating 
system also provides key drivers for networking and communications and makes t
hem available to applications and drivers.  Planned a

--
※ 来源:．哈工大紫丁香WWW bbs.hit.edu.cn. [FROM: 203.123.2.2]