Сообщение Re: Про варианты многопоточного взаимодействия... от 19.10.2023 13:39
Изменено 19.10.2023 13:44 Sm0ke
Re: Про варианты многопоточного взаимодействия...
Здравствуйте, 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 статиков, то желательно иметь возможность задать способ хранения и доступа в каждом конкретном случае явно.
В каких случаях происходит (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 статиков, то желательно иметь возможность задать способ хранения и доступа в каждом конкретном случае явно.
Re: Про варианты многопоточного взаимодействия...
Здравствуйте, 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 статиков, то желательно иметь возможность задать способ хранения и доступа в каждом конкретном случае явно.
В каких случаях происходит (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 статиков, то желательно иметь возможность задать способ хранения и доступа в каждом конкретном случае явно.