Здравствуйте, Shmj

В каких случаях происходит (data race) гонка?

* Когда один поток пишет в ту же ячейку, откуда другой в то-же время читает
Верно?

* Когда оба пишут в одну ячейку
Верно?

* А будет ли гонка, когда все только читают?
С железом, где это причина для гонки, то наверно лучше копировать для каждого thread

--

С точки зрения статиков.

Разделим статики на две группы:
1: readonly
2: mutable

1) Если взять только readonly статики, и дать к ним доступ из разных потоков без синхронизации, то будет ли data race?
Тут есть нюанс. Насколько readonly есть deep ?
Скажем есть const obj, а в нём mutable .prop — то как быть?
Для const-full-depth вроде понятно.

2) подРазвилка для mutable:

2.а)
скопировать mutable статики до запуска каждого нового thread
плюсы: быстрее к ним доступ, проще код, отсутсвтие deadlock -ов
минусы: занимает больше памяти; рассинхрон по значением после изменений; время будет потрачено на копирование;

2.б)
Отдельный thread работает с mutable статиками через сообщения
Механизм сообщений между потоками мне неизвестен.
Сколько байт можно передать?
Нужно ли знать все типы хранимых данных?

2.б.Х) А если сама структура типа является mutable прямо в run-time? -- Как быть с другими потоками, которые работают с mutable типом?
По идее в значении хранить указатель на версию _текущего_ типа
При динамиеском изменении структуры типа — делать COW типа. Так уже имеющиеся значения не потеряют целостность.
Вроде бы... (привет, методы)

А новые значения по новой версии типа — сравнимы ли со старыми?

Предполагаемый ответ:
Если не отказываться от mutable статиков, то желательно иметь возможность задать способ хранения и доступа в каждом конкретном случае явно.

Здравствуйте, Shmj

В каких случаях происходит (data race) гонка?

* Когда один поток пишет в ту же ячейку, откуда другой в то-же время читает
Верно?

* Когда оба пишут в одну ячейку
Верно?

* А будет ли гонка, когда все только читают?
С железом, где это причина для гонки, то наверно лучше копировать для каждого thread

--

С точки зрения статиков.

Разделим статики на две группы:
1: readonly
2: mutable

1) Если взять только readonly статики, и дать к ним доступ из разных потоков без синхронизации, то будет ли data race?
Тут есть нюанс. Насколько readonly есть deep ?
Скажем есть const obj, а в нём mutable .prop — то как быть?
Для const-full-depth вроде понятно.

2) подРазвилка для mutable:

2.а)
скопировать mutable статики до запуска каждого нового thread
плюсы: быстрее к ним доступ, проще код, отсутсвтие deadlock -ов
минусы: занимает больше памяти; рассинхрон по значением после изменений; время будет потрачено на копирование;

2.б)
Отдельный thread работает с mutable статиками через сообщения
Механизм сообщений между потоками мне неизвестен.
Сколько байт можно передать?
Нужно ли знать все типы хранимых данных?

2.б.Х) А если сама структура типа является mutable прямо в run-time? -- Как быть с другими потоками, которые работают с mutable типом?
По идее в значении хранить указатель на версию _текущего_ типа // для readonly типа — можно и не хранить
При динамиеском изменении структуры типа — делать COW типа. Так уже имеющиеся значения не потеряют целостность.
Вроде бы не должны... (привет, методы)

А новые значения по новой версии типа — сравнимы ли со старыми?

--

Какой подход вам кажется более удобным и почему?

Предполагаемый ответ:
Если не отказываться от mutable статиков, то желательно иметь возможность задать способ хранения и доступа в каждом конкретном случае явно.