|
| 1 | +# SharedPtr (V1 — наивный AcqRel) |
| 2 | + |
| 3 | +**SharedPtr** — указатель с подсчётом ссылок (аналог `std::shared_ptr` / `Arc`), демонстрирующий использование |
| 4 | +`memory_order_acq_rel` на RMW-операциях (Read-Modify-Write). |
| 5 | + |
| 6 | +## Структура |
| 7 | + |
| 8 | +``` |
| 9 | + SharedPtr SharedInner (heap) |
| 10 | + ┌─────────┐ ┌──────────────────────────┐ |
| 11 | + | inner |──────>| ref_count: AtomicUsize | |
| 12 | + └─────────┘ | data: T | |
| 13 | + └──────────────────────────┘ |
| 14 | +``` |
| 15 | + |
| 16 | +- `inner` — сырой указатель на аллоцированный в куче `SharedInner` |
| 17 | +- `ref_count` — атомарный счётчик ссылок |
| 18 | +- `data` — пользовательские данные |
| 19 | + |
| 20 | +## Почему AcqRel |
| 21 | + |
| 22 | +В предыдущих примерах (SpinLock, Lazy, SPSC) мы использовали отдельные `Acquire`-load и `Release`-store. |
| 23 | +Это работает, потому что load и store — разные операции на разных шагах. |
| 24 | + |
| 25 | +В SharedPtr ситуация другая: `fetch_add` и `fetch_sub` — **RMW-операции**, которые одновременно |
| 26 | +читают и пишут. Для RMW-операций `AcqRel` означает: |
| 27 | + |
| 28 | +- **Acquire-часть** (чтение): видит все записи, опубликованные предшествующими Release-операциями |
| 29 | +- **Release-часть** (запись): публикует все записи этого потока для последующих Acquire-наблюдателей |
| 30 | + |
| 31 | +## Memory Orders |
| 32 | + |
| 33 | +### `clone` |
| 34 | + |
| 35 | +```rust |
| 36 | +fn clone(&self) -> Self { |
| 37 | + unsafe { &*self.inner } |
| 38 | + .ref_count |
| 39 | + .fetch_add(1, Ordering::AcqRel); // (1) |
| 40 | + Self { inner: self.inner } |
| 41 | +} |
| 42 | +``` |
| 43 | + |
| 44 | +| # | Операция | Memory order | Обоснование | |
| 45 | +| --- | --------------------- | ------------ | ------------------------------------------------------------------------------------------------- | |
| 46 | +| 1 | `ref_count.fetch_add` | **AcqRel** | RMW: Release публикует инкремент, Acquire видит текущее состояние ref_count в modification order. | |
| 47 | + |
| 48 | +### `drop` |
| 49 | + |
| 50 | +```rust |
| 51 | +fn drop(&mut self) { |
| 52 | + let prev = unsafe { &*self.inner } |
| 53 | + .ref_count |
| 54 | + .fetch_sub(1, Ordering::AcqRel); // (2) |
| 55 | + |
| 56 | + if prev == 1 { |
| 57 | + unsafe { drop(Box::from_raw(self.inner)); } // (3) |
| 58 | + } |
| 59 | +} |
| 60 | +``` |
| 61 | + |
| 62 | +| # | Операция | Memory order | Обоснование | |
| 63 | +| --- | ---------------------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |
| 64 | +| 2 | `ref_count.fetch_sub` | **AcqRel** | RMW: Release публикует все записи потока (модификации данных через `&T`). При `prev == 1` Acquire гарантирует видимость всех записей всех потоков, делавших предыдущие `fetch_sub`. | |
| 65 | +| 3 | `Box::from_raw` (деструктор) | — | Безопасно: AcqRel на (2) при `prev == 1` установил happens-before со всеми предыдущими drop-операциями через release sequence. | |
| 66 | + |
| 67 | +## Release Sequence |
| 68 | + |
| 69 | + |
| 70 | + |
| 71 | +На диаграмме сценарий с тремя потоками: |
| 72 | + |
| 73 | +- **T1** создаёт объект `Bar()`, передаёт указатель `p` в другой поток через **mo** (modification order) |
| 74 | +- `p → Foo()`: второй поток обращается к данным через `deref` |
| 75 | +- **`fa`** (`fetch_add`, 1 -> 2): clone с `Relaxed`, инкрементирует refcount |
| 76 | +- **`fs`** (`fetch_sub`, 2 -> 1 и 1 -> 0): drop с `Release`, декрементирует refcount |
| 77 | +- **`fa rlx`** (1 -> 2): промежуточная RMW-операция, часть release sequence |
| 78 | +- Последний `fs` (1 -> 0) с `AcqRel` / `fence(Acquire)`: синхронизируется со всей **release sequence headed by `fs`**, вызывает деструктор |
| 79 | + |
| 80 | +Ключевой момент: `synchronizes-with` работает через промежуточные потоки. |
| 81 | + |
| 82 | +``` |
| 83 | +T1 (clone) T2 (drop) T3 (drop, последний) |
| 84 | +────────── ───────── ──────────────────── |
| 85 | +fetch_add(AcqRel) |
| 86 | + 1 -> 2 |
| 87 | + fetch_sub(AcqRel) |
| 88 | + 2 -> 1 |
| 89 | + fetch_sub(AcqRel) |
| 90 | + 1 → 0 |
| 91 | + <- видит ВСЕ записи T1 и T2 |
| 92 | + drop(Box::from_raw) |
| 93 | +``` |
| 94 | + |
| 95 | +Все `fetch_add`/`fetch_sub` — RMW-операции в **modification order** атомика `ref_count`. |
| 96 | +Они образуют **release sequence**, headed by первым Release store. |
| 97 | + |
| 98 | +Согласно стандарту ([atomics.order#2](https://eel.is/c++draft/atomics.order#2.sentence-1)): |
| 99 | + |
| 100 | +> Release store `A` **synchronizes-with** acquire load `B`, если `B` читает значение |
| 101 | +> из **release sequence headed by `A`**. |
| 102 | +
|
| 103 | +Поэтому T3, выполняя `fetch_sub(AcqRel)` и получая `prev == 1`, синхронизируется со всей |
| 104 | +цепочкой предыдущих RMW-операций и видит побочные эффекты всех потоков перед вызовом деструктора. |
| 105 | + |
| 106 | +## Оптимизация |
| 107 | + |
| 108 | +Эта версия использует AcqRel **везде** — это корректно, но избыточно. См. `SharedPtrV2` для |
| 109 | +оптимизированной версии с `Relaxed` / `Release` + `fence(Acquire)`, как в `std::sync::Arc`. |
0 commit comments