Checkpoint — jobs & safety

01why

Why is the data race feared far more than an ordinary bug, even though the underlying problem (entities are independent) isn't sequential?

1. aRaces always crash the program immediately
2. bRaces are nondeterministic — timing-dependent corruption that doesn't reproduce, shows no stack trace, and breaks the reproduce-inspect-fix loop
3. cRaces only happen on specific CPU brands
4. dRaces are actually easy; the fear is exaggerated

02why

A job is a struct with data fields and an Execute method. Why does that specific shape make safety checkable?

1. aStructs are faster than classes
2. bThe job's entire memory relationship is declared in its fields (which arrays, read vs write), so the system can compare declarations across jobs and detect conflicts before running anything
3. cExecute methods can't contain bugs
4. dThe struct shape lets Burst skip the loop

03how

When you schedule a job that writes an array another scheduled job also uses, with no ordering declared, the job system:

1. aRuns them anyway and hopes for the best
2. bRefuses to schedule — throws a deterministic error at schedule time, on the main thread, naming the conflicting jobs and container
3. cSilently serializes them with no notice
4. dCrashes at a random later frame

04why

In what sense is a data race 'the same question as aliasing, one level up'?

1. aThey're unrelated; the phrasing is loose
2. bBoth are a write and an access to overlapping memory with no ordering between them — aliasing asks it between pointers within a loop, a race asks it between jobs across cores
3. cAliasing is about integers, races about floats
4. dBoth only occur in managed code

05why

Why can ten jobs that all read the same [ReadOnly] NativeArray run simultaneously, but ten jobs writing it cannot?

1. a[ReadOnly] arrays are copied per job
2. bTwo readers never overlap-with-a-write, so no race exists among them; but any writer creates a write/access overlap that must be serialized to stay correct
3. cThe scheduler picks readers over writers arbitrarily
4. dWriters are slower, so they're queued

06why

You mark a container [ReadOnly] to get concurrent readers, then write to it through a stashed pointer inside the job. What happens?

1. aThe safety system catches it and errors
2. bYou reintroduce the exact nondeterministic race the system prevents — concurrent access the checker believed were all reads, failing silently at runtime
3. cThe write is ignored
4. dIt's fine as long as only one job does it

07what

Who owns the worker threads, and what do you provide?

1. aYou spawn and join threads; the system provides the CPU
2. bThe job system owns a worker-thread pool (≈one per core); you provide job descriptions and it schedules them across threads
3. cEach job creates its own thread on Schedule
4. dThe GPU owns the threads