Runtime & concurrency
using System;
using System.Linq;
using System.Collections.Generic;
using System.Collections.Concurrent;
using System.Reflection;
using System.Linq.Expressions;
using System.Threading;
using System.Threading.Tasks;
int first = Work(10);
bool stable = true;
for (int run = 0; run < 20; run++) stable &= Work(10) == first;
Console.WriteLine($"value:{first}");
Console.WriteLine($"stable:{stable}");
static int Work(int count) { int total = 0; for (int i = 0; i < count; i++) total = checked(total + i); return total; }
Reveal answer and reasoning
Work adds zero through nine, producing forty-five. Twenty subsequent calls compare their result with that retained value, so the output is value:45 and stable:True. The independently known arithmetic answer matters as well as repeatability. If Work returned a constant wrong value, the stability comparison alone could still be true, but the expected value line would reveal the disagreement.
No JIT flag, tier identifier, native instruction, or elapsed time is printed by this portable snippet. A common wrong answer appends an optimization conclusion because the code has a loop named warmup in its surrounding discussion. The actual external project has separate observed diagnostics, and even those flags do not identify Work's tier. These two lines prove the bounded calculation and repeated result, not speed, native compilation strategy, or a performance ranking against another runtime.
What a strong answer covers
- The arithmetic result is forty-five.
- Stable is a repeated-result relationship.
- The snippet contains no tier measurement.
Common pitfall
Reading a semantic stability loop as a runtime optimization detector.
Follow-up questions
- What changes for a count of five?
- What additional evidence would identify actual code generation?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.