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

WH>О чем я тебе уже сколько лет говорю?

Я не знаю зачем ты мне что-то говоришь. Я объяснял человеку общие идеи и развеивал его сомнения.

Меня за советскую власть агитировать не надо.

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

V>>А если нам эти гонки принципиально нужны для lock-free алгоритмов?
WH>Язык и стандартная библиотека с большим запасом покроют потребности примерно 100% пользователей.
WH>А те пара человек, которым не хватит используют unsafe.
WH>И это если не вспоминать о том, что примерно 99% программистов lock-free структуру данных написать не смогут.

Ну, простейшим lock-free как раз 99% программистов пользуются регулярно.
Через т.н. "relaxing memory order":

void someThreadProc(bool volatile * cancel) {
  while(!*cancel) 
    doSmth();
}

...
bool volatile cancel = false;
Thread thread1(someThreadProc, &cancel);
Thread thread2(someThreadProc, &cancel);
Thread thread3(someThreadProc, &cancel);

bla_bla_bla();
cancel = true;

Т.е., даже если заменить bool на некий библиотечный atomic<bool>::store/load (где происходящее в точности аналогично в случае memory_order_relaxed) — все-равно у нас торчит ссылка на расшаренный объект в двух потоках.

Да, я помню про твои "каналы".
Но это ж из пушки по воробьям. ))

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

V>Ну, простейшим lock-free как раз 99% программистов пользуются регулярно.
V>Через т.н. "relaxing memory order":
1)Я сказал написать, а не пользоваться.
2)Большая часть программистов даже не поймёт, что тут написано.
3)Это тупая и не переносимая реализация cancellation token.
Естественно cancellation token как и многие другие примитивы будут в поставке.

V>Да, я помню про твои "каналы".
V>Но это ж из пушки по воробьям. ))
Каналы — это ещё один очень полезный инструмент.

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

VD>Я не знаю зачем ты мне что-то говоришь. Я объяснял человеку общие идеи и развеивал его сомнения.
То, что ты тут пересказываешь.

VD>Меня за советскую власть агитировать не надо.
С тобой всегда так. Сначала "чё за чушь", через пару лет "я всегда так говорил".
Просто ты ещё сам не до конца понял, что реализовать можно, а что нет.
Вот я тебе и пояснил где ты заблуждаешься.

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

WH>2)Большая часть программистов даже не поймёт, что тут написано.

Эээ... не там ты работал и работаешь... ))


WH>3)Это тупая и не переносимая реализация cancellation token.
WH>Естественно cancellation token как и многие другие примитивы будут в поставке.

Ну, тут мой ответ и за 10 лет не поменялся:
я вижу слабость таких рассуждений в заведомой зависимости от содержимого "изкаробки", получая резко меньшие возможности для маневра/экспериментов, т.е. для построения своих примитивов.

Я думаю, тут надо спускаться на самый низ и давать тупо базу, а всякие cancellation token пусть будет сугубо библиотечной приблудой, написанной честным образом прямо в языке.

Достаточно взять ровно четыре минимальных базовых примитивов для многопоточности:
— атомарное чтение слова
— атомарная запись слова
— безусловный обмен
— условный обмен

По желанию можно добавить еще операции (если процессор поддерживает):
— атомарные инкремент/декремент
— или даже атомарное прибавление/вычитание
В любом случае, эти последние выражаются через первые, даже если проц не умеет их прямо.

Рисуем "системную" базу:
(некий псевдо-язык, в котором все типы уникальные)

type Atomic { /* тут указатель на машинное слово, в языке не представимо */};

Atomic dup(Atomic); // копия указателя

Word read(Atomic);
void write(Atomic, Word);
Word exchange(Atomic, Word);
Word compare_exchange(Atomic, Word, Word);

Ну и всё.

Теперь твои "каналы", "cancellation tokens" и вообще любые желаемые вещи можно выразить прямо ср-вами языка.

===========
Будет ли там GC или подсчет ссылок для расшаренного машинного слова — не принципиально.

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

WH>>2)Большая часть программистов даже не поймёт, что тут написано.
V>Эээ... не там ты работал и работаешь... ))
Ты представления не имеешь где я работал и работаю.

V>Я думаю, тут надо спускаться на самый низ и давать тупо базу, а всякие cancellation token пусть будет сугубо библиотечной приблудой, написанной честным образом прямо в языке.
Перестающем работать при переносе на другую железку.

V>Достаточно взять ровно четыре минимальных базовых примитивов для многопоточности:
Не нужен этот ад при прикладной разработке.

V>Теперь твои "каналы", "cancellation tokens" и вообще любые желаемые вещи можно выразить прямо ср-вами языка.
Только никакого контроля со стороны компилятора не будет.
А значит можно оставаться на С++.

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

WH>>>2)Большая часть программистов даже не поймёт, что тут написано.
V>>Эээ... не там ты работал и работаешь... ))
WH>Ты представления не имеешь где я работал и работаю.

Да тут половина КЫВТ прекрасно об этом в курсе. ))
И по прошлому и по недавнему настоящему.


V>>Я думаю, тут надо спускаться на самый низ и давать тупо базу, а всякие cancellation token пусть будет сугубо библиотечной приблудой, написанной честным образом прямо в языке.
WH>Перестающем работать при переносе на другую железку.

Если железка не поддерживает какую-то одну из 4-х базовых операций, то эта железка не для многоядерности. На такой железке многопоточность у нас будет работать на одном физическом ядре, а указанные примитивы реализуются через запрет прерываний, выполнение "атомарного" кода и разрешение прерываний.


V>>Достаточно взять ровно четыре минимальных базовых примитивов для многопоточности:
WH>Не нужен этот ад при прикладной разработке.

В прикладной разработке будут прикладные библиотеки.
Цимус в том, что произвольные прикладные библиотеки становится возможным разрабатывать ср-вами безопасного языка, а не вкладывать их в некую магическую "поставку".


V>>Теперь твои "каналы", "cancellation tokens" и вообще любые желаемые вещи можно выразить прямо ср-вами языка.
WH> Только никакого контроля со стороны компилятора не будет.

Я дал для случая uniqueness-типов.
Куда уж больший контроль-то?

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

V>Цимус в том, что произвольные прикладные библиотеки становится возможным разрабатывать ср-вами безопасного языка, а не вкладывать их в некую магическую "поставку".
Хватит пороть чушь. Ей больно.
Никаких гарантий со стороны компилятора на этих примитивах ты не получишь.

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

V>>Цимус в том, что произвольные прикладные библиотеки становится возможным разрабатывать ср-вами безопасного языка, а не вкладывать их в некую магическую "поставку".
WH>Хватит пороть чушь. Ей больно.
WH>Никаких гарантий со стороны компилятора на этих примитивах ты не получишь.

Со стороны компилятора нам требуется строгая типизация и uniqueness-семантика.
Cо стороны железки требуется атомарность этих операций.
Вот и всех делов. А то опять развели обсуждения не в ту степь. ))

Каждый процесс (поток) пусть владеет своим типобезопасным экземпляром Atomic, каждый из которых "унутре" пусть ссылается на одну и ту же структуру в памяти. Atomic должен быть встроенным opaque-типом, навроде встроенных integer.

Базис для операций над Atomic уже дал.