Editing Worst-case execution time (section)

=== Considerations ===
The problem of finding WCET by analysis is equivalent to the [[halting problem]] and is therefore not solvable in the general. Fortunately, for the kind of systems that engineers typically want to find WCET for, the software is typically well structured, will always terminate and is analyzable.

Most methods for finding a WCET involve approximations (usually a rounding upwards when there are uncertainties) and hence in practice the exact WCET itself is often regarded as unobtainable. Instead, different techniques for finding the WCET produce estimates for the WCET.<ref>"[http://moss.csc.ncsu.edu/~mueller/ftp/pub/mueller/papers/1257.pdf The worst-case execution-time problem—overview of methods and survey of tools]", Wilhelm, Reinhard, et al., ACM Transactions on Embedded Computing Systems (TECS), Vol. 7, No. 3, 2008.</ref> Those estimates are typically pessimistic, meaning that the estimated WCET is known to be higher than the real WCET (which is usually what is desired). Much work on WCET analysis is on reducing the pessimism in analysis so that the estimated value is low enough to be valuable to the system designer.

WCET analysis usually refers to the execution time of single thread, task or process.  However, on modern hardware, especially multi-core, other tasks in the system will impact the WCET of a given task if they share cache, memory lines and other hardware features.  Further, task scheduling events such as [[Blocking (scheduling)|blocking]] or to be [[interrupt]]ions should be considered in WCET analysis if they can occur in a particular system.  Therefore, it is important to consider the context in which WCET analysis is applied.