Здравствуйте, Shmj, Вы писали:

S>1. Вот есть стандартное решение — типа как в С++. Вы запускаете поток и как бы просто исполнение раздвоилось. Теперь нужно помнить, что к одной и той же переменной могут одновременно получит доступ два разных потока — как-то синхронизировать эти доступы, учитывать это.
С++ много чего есть, но не обязательно пользоваться примитивами.

S>У меня на адаптацию мозга к пониманию многопоточности ушло несколько месяцев.
Это норма.

S>2. ... Доступ к переменным всегда из одного потока — нет возможности раздвоить как в C++. ...
В С++ это легко достигается.

S>Если же вам в этом подходе захотелось запустить отдельный поток — то он имеет все свои значения переменных, включая статические. Т.е. с первым потоком оно никак не соотносится. По сути как будто запустился второй экземпляр программы. Общение между ними — через спец. механизм — как будто вы общаетесь с удаленным сервером.
Это уже третий подход — обмен сообщениями.

S>Подход 2 — не требует адаптации мозга и воспринимается интуитивно. Но тоже есть беда — некоторые вещи допустимы только из основного потока. В таком случае вам нужно делать некий спец. вызов — перегонку туда-обратно чисто из-за данной специфики
А кто сказал, что будет легко?

S>Какой подход вам кажется более удобным и почему?
У каждого решения есть свои плюсы и недостатки.

Кстати, есть ещё подход, когда под каждую операцию запускается отдельный поток исполнения. В этом случае переменные вообще не передаются между нитками — есть только входные данные и результаты.

Здравствуйте, Shmj, Вы писали:

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

Александреску А. Язык программирования D. – Пер. с англ. – СПб.: Символ-Плюс, 2012

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

Удобных нет, Потому что нужно держать все в голове.
Ну а голова у нас как известно очень слабая.
Одновременно не более 4 вещей держит в голове.
Но самое ужасное, это врожденная лень, когда задача не хочет лезть в голову.
Все упирается в извечный вопрос: НАФИГА?

Удобней всего запускать отдельный микросервис в отдельной программе и общаться по HTTP, а блокировки пускай база разруливает через транзакции. А ещё удобней вообще ничего не делать, и пойти кушать пиццу. Но не всегда это возможно. Поэтому тут вопрос об удобстве не совсем верный. Блокировки или лок-фри алгоритмы это зло, но от него порой не уйти, они дают максимальную производительность.

Я бы так классифицировал подходы:

1. Доступ к общей памяти (блокировки или локфри). Самый сложный в реализации, но самый производительный.

2. Обмен сообщениями (ерланг и его клоны). Требует качественной библиотечной поддержки, неизбежно несёт некоторые расходы.

3. Транзакционная память (ныне штука почти не встречающаяся, но любопытно). Этим не пользовался, предполагаю, что этот подход самый простой и понятный в использовании, но для производительности нужна поддержка на уровне железа.

Здравствуйте, Shmj, Вы писали:

S>Подход 2 — не требует адаптации мозга и воспринимается интуитивно. Но тоже есть беда — некоторые вещи допустимы только из основного потока. В таком случае вам нужно делать некий спец. вызов — перегонку туда-обратно чисто из-за данной специфики

У меня наоборот. Более понятна первая схема. В голову укладывается как совместная работа команды с необходимостью иногда синхронизировать свои действия.

Здравствуйте, Sm0ke, Вы писали:

S>А можно ли эту задачу решить на уровне железа?
S>Спроектировать такую архетектуру, в которой не будет проблемы data race вообще?

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