Lehet, hogy "konkurrens" elérés helyett "fizikailag egy időben"-re gondolsz? Föltételezek Rólad annyi hátteret, hogy tudod: "fizikailag egy időben" nem lehet, a RAM-nak is egy címbusza, egy adatbusza, kizárólagos vezérlőjelei vannak (gondolom nem dual-port RAM-ról akarsz beszélni, az kissé speciális állat). Én végig data race condition elkerüléséről írtam.
Inkább leírom. Van egy buffered, amit a main() allokált és átadja a szálaknak. Van annyi szálad, amennyi CPU magod és ezek ebbe a bufferbe írkálnak. Párhuzamosan. Minden szál ugyanazt a pointert kapta meg (én C-ben gondolkodok, te majd fordítasz Rust-ra), de más-más offsettel dolgoznak és egymás területéhez nem nyúlnak. Ebben a példában hogyan oldja meg a Rust a data race-t? Ha kikényszeríti a szemaforhasználatot, akkor "egyszerre" csak egy thread fér hozzá, a többinek meg kell várnia, egyébként pedig a szálak (azaz a magok) simán írhatják a memóriát "egyszerre", mert nem bántják egymás adatait. (Igen, tudom, hogy a RAM-hoz egyszerre csak egy fér hozzá, nem erről van szó, hanem az egymásra várásról. És nem, direkt nincs split, tudom, hogy ha nincs overlap, akkor fel is lehetne szeletelni a területet több pointerre; elméleti a kérdés.)
Az ellenjavallt és az ördögtől való, az két különböző dolog.
Inkább két külön szintje ugyanannak a dolognak. Ezek eszközök. Nincs olyan, hogy valami generikusan ellenjavallt.
Én biztos nem fogom Neked megtiltani. :)
Oh, köszönöm a kegyet. :)
A globális változóról: ezt sem tilos. Amikor kell, akkor kell, csak ismerni kell a hátrányait:...
Kösz, hogy leírtad; magyarán ha van egy globális változód és a hozzáférésnél nem "burkolod" szemaforokkal, akkor a Rust beszól érte, azaz kötelezően lassít, akkor is, ha nincs lehetőség ütközésre. Mi a helyzet az 1-eshez adott példával? Az elméletileg nem globális változós, csak a main() által allokált terület van globálisan használva. Csak mert, ha arra ugyanez vonatkozik, akkor belassítja az egész procedúrát.