D vs C++ , почти сурковская пропаганда: не пора ли C++ потихоньку готовиться к пенсии?

Цитата D_KEY @ 16.11.15, 12:22

Можешь придумать похожую на твою, но более простую задачку, чтобы можно было поэкспериментировать?

Поэкспериментировать на какую тему?

Цитата applegame @ 16.11.15, 12:31

Цитата D_KEY @ 16.11.15, 12:22

Можешь придумать похожую на твою, но более простую задачку, чтобы можно было поэкспериментировать?

Поэкспериментировать на какую тему?

Ну на тему иммутабельности, GC, RC, разделяемых ресурсов, очередей/каналов и пр. Там видно будет.

Цитата D_KEY @ 16.11.15, 12:38

Ну на тему иммутабельности, GC, RC, разделяемых ресурсов, очередей/каналов и пр. Там видно будет.

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

Добавлено 16.11.15, 12:49
Кроме того нас ограничивает внешнее 3rd party API. Если бы не оно мы могли бы вообще отказаться от совместного доступа к объектам, передавая только их уникальные идентификаторы.

Сообщение отредактировано: applegame - 16.11.15, 12:49

Цитата applegame @ 16.11.15, 12:41

Цитата D_KEY @ 16.11.15, 12:38

Ну на тему иммутабельности, GC, RC, разделяемых ресурсов, очередей/каналов и пр. Там видно будет.

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

Да нужно что-то более конкретное. Т.е. обозначить, что за контейнер, как данные туда попадают, как удаляются, кто, как и когда их читает и что, собственно, с этими данными делает. Что-то надо придумать. Тогда можем поиграться(в том числе и на Go вариант может появиться).

Цитата D_KEY @ 16.11.15, 12:50

Да нужно что-то более конкретное. Т.е. обозначить, что за контейнер, как данные туда попадают, как удаляются, кто, как и когда их читает и что, собственно, с этими данными делает. Что-то надо придумать. Тогда можем поиграться(в том числе и на Go вариант может появиться).

А смысл? Проверить что быдет быстрее GC или RC? Придумай сам что-нибудь с передачами групп объектов и типа их обработкой Я-то свою задачу решил и решение работает хорошо и, главное, поддерживается и расширяется тоже хорошо. Могут быть проблемы с масштабированием, но я полагаю, что мы вряд ли в обозримом будущем упремся в потолок текущей архитектуры.

Сообщение отредактировано: applegame - 16.11.15, 12:55

Цитата applegame @ 16.11.15, 12:54

Придумай сам что-нибудь с передачами групп объектов и типа их обработкой

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

Цитата applegame @ 16.11.15, 12:54

я полагаю, что мы вряд ли в обозримом будущем упремся в потолок текущей архитектуры

Так а какова сама задача, для которой была придумана такая архитектура?

То что мне приходит в голову не требует копирования или совместного доступа, достаточно обмениваться уникальными идентификаторами, что в общем-то не эффективней обмена сырыми указателями, но зато не требует GC. Разве что прописать в условиях задачи необходимость полного доступа к объекту в потоках.

Добавлено 16.11.15, 13:10

Цитата MyNameIsIgor @ 16.11.15, 13:06

Так а какова сама задача, для которой была придумана такая архитектура?

Подробности разглашать не могу, так как оно коммерческое и проприетарное.

Цитата applegame @ 16.11.15, 13:09

То что мне приходит в голову не требует копирования или совместного доступа, достаточно обмениваться уникальными идентификаторами

Это не то же самое, ибо тогда получившие идентификатор не будут владеть данными. Со сборщиком мусора или подсчётом ссылок они ими владеют, даже если данные удалены из контейнера.

Добавлено 16.11.15, 13:14

Цитата applegame @ 16.11.15, 13:09

Подробности разглашать не могу, так как оно коммерческое и проприетарное.

Эммм... Ну, хз, конечно... Но что тайного, например, в такой формулировке "сервис должен получать такие-то запросы (примерная вероятность, периодичность) и отдавать такие-то ответы"?

Цитата MyNameIsIgor @ 16.11.15, 13:12

Это не то же самое, ибо тогда получившие идентификатор не будут владеть данными. Со сборщиком мусора или подсчётом ссылок они ими владеют, даже если данные удалены из контейнера.

Я и не говорил, что это одно и тоже. Я имел в виду, что упрощенный пример задачи пришедший мне в голову не требует владения/совместного доступа, а достаточно идентификатора.

Добавлено 16.11.15, 13:19

Цитата MyNameIsIgor @ 16.11.15, 13:12

Но что тайного, например, в такой формулировке "сервис должен получать такие-то запросы (примерная вероятность, периодичность) и отдавать такие-то ответы"?

Проблема в том, что в такой трактовке это будет слабо связано с реальной задачей. То есть если мы подберем наиболее удачный алгоритм, совершенно не факт, что он будет удачным в нашем реальном проекте. Но я попробую сформулировать нечто попроще. Будет эдакий многопоточный бенчмарк, пусть даже не похожий на реальный проект. Такое устроит?

Цитата applegame @ 16.11.15, 13:15

Проблема в том, что в такой трактовке это будет слабо связано с реальной задачей. То есть если мы подберем наиболее удачный алгоритм, совершенно не факт, что он будет удачным в нашем реальном проекте.

Ну, я имел в виду, что можно отделить то, что попадает под соглашение о неразглашении (форматы данных, область применения, алгоритмы и т.д.), от чисто технических подробностей - измеряемых параметров, которым должен удовлетворять сервис.

Цитата applegame @ 16.11.15, 13:15

Но я попробую сформулировать нечто попроще. Будет эдакий многопоточный бенчмарк, пусть даже не похожий на реальный проект. Такое устроит?

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

Сообщение отредактировано: MyNameIsIgor - 16.11.15, 13:25

Цитата applegame @ 16.11.15, 11:07

Наверное думал, раз написал:

Цитата korvin @ 14.11.15, 20:13

Нет, указатель может стать невалидным, если поток-владелец вызвал деструктор объекта, пока поток, получивший от него указатель на данные, ещё не завершился.

Или решил, что речь идет о C++. Но тогда стоило бы написать, что ты говорил о другом языке, вместо благодарностей капитанам, нет?

Мы же обсуждали указатели и владение памятью при использовании иммутабельных объектов в многопоточной среде в языках без GC.

Цитата applegame @ 16.11.15, 11:07

А какая связь между владением ресурсом и совместным доступом к ресурсу?

Прямая:
- с GC владельцем является GC и он же освобождает память. Т.е. имея ссылку на один и тот же ресурс оба потока будут иметь её до тех пор пока оба не завершаться.
- Без GC программист сам выбирает политику владения памятью и организовывает совместный доступ таким образом, чтобы не было дыр, позволяющих привести систему к некорректному состоянию.

Вот тебя не устраивает smart_ptr из-за каких-то там проблем, я тебе предлагаю [не использовать smart_ptr и не шарить сам ресурс напрямую (через какие бы то ни было указатели вообще)] и не иметь этих проблем.

Добавлено 17.11.15, 21:23
Давай хоть для начала определимся, что это за ресурс.

Цитата korvin @ 17.11.15, 21:10

Мы же обсуждали указатели и владение памятью при использовании иммутабельных объектов в многопоточной среде в языках без GC.

Я полагал, что мы обсуждаем замену иммутабельным объектам в языке с GC.

Цитата korvin @ 17.11.15, 21:10

Прямая:
- с GC владельцем является GC и он же освобождает память. Т.е. имея ссылку на один и тот же ресурс оба потока будут иметь её до тех пор пока оба не завершаться.
- Без GC программист сам выбирает политику владения памятью и организовывает совместный доступ таким образом, чтобы не было дыр, позволяющих привести систему к некорректному состоянию.

Как ты там говорил? Спасибо, кэп. Но владение ресурсом и совместный доступ - понятия ортогональные. Совместный доступ - проблема синхронизации, владение ресурсом - проблема времени жизни ресурса.

Цитата korvin @ 17.11.15, 21:10

Вот тебя не устраивает smart_ptr из-за каких-то там проблем, я тебе предлагаю [не использовать smart_ptr и не шарить сам ресурс напрямую (через какие бы то ни было указатели вообще)] и не иметь этих проблем.

Я такого не говрил. Я говорил что по крайней мере в моем проекте immutable + GC удобнее, чем shared_ptr и может быть эффективней. А ты как-то странно заявил, что совместный доступ не нужен, если владелец всего один. Прямо вот совсем никогда не нужен? Создал объект в одном потоке раздал указатель на него еще десятерым, подождал пока они завершаться, уничтожил объект. Вот тебе схема с одним владельцем и совместным доступом.

В любом случае я тебя понял, такой вариант не всегда удобен и эффективен, но кое-где я его применяю.

Сообщение отредактировано: applegame - 17.11.15, 21:38

Цитата applegame @ 17.11.15, 21:33

Но владение ресурсом и совместный доступ - понятия ортогональные.

Нет, если доступ требует владения, как в случае с shared_ptr.

Добавлено 17.11.15, 21:52

Цитата applegame @ 17.11.15, 21:33

Создал объект в одном потоке раздал указатель на него еще десятерым, подождал пока они завершаться, уничтожил объект. Вот тебе схема с одним владельцем и совместным доступом.

Э-э... Если ты ждешь пока потоки завершатся, то зачем тебе GC, если объект прекрасно и безопасно удалится создателем? Полезность GC проявляется как раз, когда ты не ждешь, пока потоки, обрабатывающие объект, завершатся, поэтому ты не можешь сам удалить объект там, где создал.

Сообщение отредактировано: korvin - 17.11.15, 21:55

Цитата applegame @ 17.11.15, 21:33

Но владение ресурсом и совместный доступ - понятия ортогональные. Совместный доступ - проблема синхронизации, владение ресурсом - проблема времени жизни ресурса.

Так вот именно. Потому наличие GC упрощает для тебя вопросы владения вне зависимости от иммутабельности(которая, в том числе, позволяет тебе не беспокоится о синхронизации).

Добавлено 17.11.15, 22:08

Цитата applegame @ 16.11.15, 13:15

Но я попробую сформулировать нечто попроще. Будет эдакий многопоточный бенчмарк, пусть даже не похожий на реальный проект. Такое устроит?

Меня бы устроило. Не факт, что как следует похоливарим, но подумать можно. А может и поиграться с реализацией будет интересно.