Názory k článku Programovací jazyk Rust: vlákna a sdílení objektů mezi nimi

„jak se bude chovat počitadlo referencí v případě, že objekt bude sdílen mezi větším množstvím vláken? Odpověď na tuto otázku je jednoznačná – funkčnost není zaručena “

Opravdu? Já myslel, že výsledek je zaručen – nezkompiluje se to.

Díky za upozornění. Asi jsem to napsal nejasně, ale myslel jsem to tak, že funkčnost není zaručena v obecném případě (bez ohledu na jazyk), proto to je v Rustu řešeno.

A ano, v Rustu by to z normálním počitadlem referencí nešlo přeložit. Asi to doplním aspoň sem do diskuze, co by se stalo při náhradě Arc za "normální" Rc:


error[E0277]: the trait bound `std::rc::Rc<­Complex>: std::marker::Send` is not satisfied
--> test.rs:52:9
|
52 | thread::spawn(move || {
| ^^^^^^^^^^^^^
|
= note: `std::rc::Rc<­Complex>` cannot be sent between threads safely
= note: required because it appears within the type `ComplexNumbe­rOwner`
= note: required because it appears within the type `[closure@tes­t.rs:52:23: 55:10 owner:Complex­NumberOwner]`
= note: required by `std::thread::spaw­n`


Výhoda reference countingu je v tom, že stále máme kontrolu nad tím, kdy se co uvolní. Některé garbage collectory (jako například standardní javový) někdy celou aplikaci prakticky zastaví. Pokud je to near-realtime aplikace, tak to může být problém.

Záleží na druhu GC. Existují i concurrent GC, které například při analýze pracují se snapshotem paměti.

Obecne bych si dovolil tvrdit ze GC bude ve vetsine pripadu rychlejsi, vyhodou RC je v podstate jen to ze nezpusobuje takove latence, coz je pro nektere aplikace kriticke a mnohem dulezitejsi nez celkova rychlost. Dale ma vetsinou RC ci ARC nizsi naroky na pamet. Samozrejme jde o to o jakem GC se bavime