Evitar condiciones de carrera

A data race happens when two threads touch the same memory at once and at least one writes. The result becomes unpredictable. ⚠️

Many workers adding into one shared total will clash. Updates get lost because writes overlap and stomp each other.

The simplest fix: give each worker its own indices to write. If outputs never overlap, there is no race.

Many threads may read the same input safely. Trouble starts only when someone writes what others read or write.

For a sum, give each worker its own partial slot. They never share a cell, so the adds stay safe.

Once all workers finish, add the partials together in a single thread. This final reduction needs no locking.

The safest parallel code shares only read-only data. Keep every mutable piece private to one worker when you can.

Workers may finish in any order. Never rely on one chunk running before another, since the schedule can vary.

Mojo's ownership and value semantics make accidental sharing harder, but parallel logic is still yours to keep correct.

Races hide behind timing, so run the parallel code many times and compare against a serial reference result.

The best defense is a layout where writes never overlap. Prevent races by design, not by patching afterward.

Several workers need to compute a single sum in parallel.

Avoid races by writing disjoint slots, using per-worker partials, reducing after joining, and never relying on order, so parallel results stay correct. 🚀