Unit — Jobs

01why

State why the job shape (data in fields, logic in Execute) is what makes safe automatic scheduling possible.

1. aStructs are stack-allocated, avoiding the GC
2. bBecause a job's every memory access is declared in its fields (which containers, read vs write), the system can compare declarations across jobs and detect conflicts before running anything — turning race-safety from discipline into a decidable check
3. cExecute methods are automatically thread-local
4. dThe struct shape lets the scheduler skip idle cores

02why

Explain the sense in which a data race and pointer aliasing are the same phenomenon.

1. aThey aren't; they're separate concerns
2. bBoth are a write and an access to overlapping memory with no ordering between them — aliasing within a loop (breaking vectorization), a race between jobs (breaking concurrency) — which is why [ReadOnly] resolves both as the disjointness promise
3. cBoth only occur with integer types
4. dBoth are caught by the garbage collector

03why

Why can many jobs reading the same [ReadOnly] array run concurrently while any writer forces serialization?

1. aReaders are assigned higher priority
2. bPure readers have no write to overlap, so no race exists among them; a writer introduces a write/access overlap that must be ordered to stay correct — making [ReadOnly] a throughput multiplier
3. c[ReadOnly] arrays live in faster memory
4. dThe scheduler runs writers last by convention

04how

An IJobEntity's Execute takes one entity's components. Why does ScheduleParallel not run one thread per entity?

1. aThreads are too expensive to make per entity
2. bThe chunk is the unit of parallel distribution (independent by construction); the generated job spreads chunks across cores, each thread running your Execute over all entities in its chunk
3. cIt does run one thread per entity, just pooled
4. dEntities are processed on the GPU in ScheduleParallel

05why

The most common jobs performance mistake, and its relationship to a structural-change sync point:

1. aToo many [ReadOnly] marks; sync points are unrelated
2. bOver-completing — a Complete after each job stalls the main thread and serializes the graph; it's the same main-thread barrier as a sync point (which force-completes in-flight jobs to move memory safely), self-inflicted
3. cScheduling too few jobs; sync points prevent this
4. dUsing IJobEntity instead of IJobChunk; sync points enforce it

06howmeasure

Build the single-vs-parallel comparison from the lab: one heavy IJobEntity via Schedule vs ScheduleParallel over ~200k entities. Enter time_Schedule / time_ScheduleParallel.

07howmeasure

Now price over-completion: a 3-job chain completed once at the end vs completed after each job. Enter time_completeEach / time_completeOnce.