К сожалению не понял глубоко скрытого смысла этого поста по отношению к моему коментарию.

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

E>>А как вы будете все это делать с GC, если все это нужно будет действительно _удалить_, а не оставить в мусоре до следующего прихода GC?
S>GC.Collect() ?

Т.е. это нормальное решение, когда какая-то подсистема приложения дергает GC всего приложения для того, чтобы очистить свои ресурсы?

Но меня вот что больше интересует: принято ли при разработке компонентов на Java или .NET где-то документировать, что компонент инициирует внутри себя сборку мусора?

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

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

Где GC может стать причиной остановки большого количества потоков для сборки мусора.

С>В свое время я набросал кое-что в блоге по этому поводу. А в библиотеке acto мне пришлось двухфазное удаление делать (так как в С++ нет GC).

В связи с этим вопрос -- а зачем было делать библиотеку на C++?

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

E>Где GC может стать причиной остановки большого количества потоков для сборки мусора.

Кстати, в java 6 научились вызывать не только stop-the-world, но и конкурентный сборщик мусора. Это снимает проблему блокирования приложения, но пропадает гарантия, что "управляемый неуправляемый" ресурс будет убран в обозримом будущем.

Здравствуйте, eao197, Вы писали:
E>Т.е. это нормальное решение, когда какая-то подсистема приложения дергает GC всего приложения для того, чтобы очистить свои ресурсы?
Это — нет. По идее, у подсистемы должен быть свой независимый GC. Но такое щасте нам будет доступно только в 100%-managed OS.

E>Но меня вот что больше интересует: принято ли при разработке компонентов на Java или .NET где-то документировать, что компонент инициирует внутри себя сборку мусора?
По разному.

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

E>>Т.е. это нормальное решение, когда какая-то подсистема приложения дергает GC всего приложения для того, чтобы очистить свои ресурсы?
S>Это — нет. По идее, у подсистемы должен быть свой независимый GC. Но такое щасте нам будет доступно только в 100%-managed OS.

А почему так категорично на счет OS? Например, если мы на языке с GC делаем текстовый процессор, то создаем его из нескольких библиотек-подсистем. Одна из подсистем отвечает за отображение структуры документа, как раз она и строит хитрые деревья с хендлами ресурсов в узлах. Когда пользователь закрывает окно с графической структурой документа, это дерево должно быть разрушено. Вроде как все работает в рамках одного процесса, причем же здесь OS?

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

E>>Т.е. это нормальное решение, когда какая-то подсистема приложения дергает GC всего приложения для того, чтобы очистить свои ресурсы?
S>Это — нет. По идее, у подсистемы должен быть свой независимый GC. Но такое щасте нам будет доступно только в 100%-managed OS.

Ничего не даст. Всё равно нужно запускать GC в контексте приложения захватившего ресурс. А это либо stop-the-world в приложении, либо без гарантии, что ресурс будет убран.

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

M>К сожалению не понял глубоко скрытого смысла этого поста по отношению к моему коментарию.

Неудивительно.

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

E>Здравствуйте, Стэн, Вы писали:

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

E>Где GC может стать причиной остановки большого количества потоков для сборки мусора.
Ведь есть же разные алгоритмы, необязательно все останавливать разом?!.. Ну и много ли имеется вариантов по данному вопросу? Когда произвольная схема многопоточности (каждый поток может взаимодействовать с любым другим), когда актеры могут произвольным образом между собой связываться и взаимодействовать... Вот как в такой системе управлять их временем жизни и при этом, по-возможности, не заставлять пользователя следить за этим самостоятельно?

С>>В свое время я набросал кое-что в блоге по этому поводу. А в библиотеке acto мне пришлось двухфазное удаление делать (так как в С++ нет GC).

E>В связи с этим вопрос -- а зачем было делать библиотеку на C++?
Не на C++, а для С++... Приходится писать на C++, ну и хочется какого-то человеческого взаимодействия между потоками. Однажды мне пришлось делать небольшую программу, где была необходимость асинхронного взаимодействия между потоками, там я использовал Windows-очередь, но это уж как-то совсем неудобно мне показалось...

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

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

E>>Здравствуйте, Стэн, Вы писали:

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

E>>Где GC может стать причиной остановки большого количества потоков для сборки мусора.
С>Ведь есть же разные алгоритмы, необязательно все останавливать разом?!.. Ну и много ли имеется вариантов по данному вопросу? Когда произвольная схема многопоточности (каждый поток может взаимодействовать с любым другим), когда актеры могут произвольным образом между собой связываться и взаимодействовать... Вот как в такой системе управлять их временем жизни и при этом, по-возможности, не заставлять пользователя следить за этим самостоятельно?


А в чём проблема? Никаких отличий от использования обычного умного указателя, например shared_ptr, для пользователя не будет.
Банально shared_ptr может делать atomic_inc/atomic_dec для счётчика ссылок, либо применять какую-то более умную схему. Но это не важно с т.з. пользователя, т.к. для него будет тот же "smart_ptr", а уж что он там делает за кулисами — не касается пользователя.
Почему у тебя там возникли проблемы — не понимаю...
Погляди реализацию в SObjectizer — там, например, когда актёру посылается сообщение, для него инкрементируется счётчик, а когда обработка завершается — декрементируется.

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

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

K>>В других языках зато либо вообще отсутсвует возможность автоматического управления ресурсами (C), либо это делается так, что хочется проклинать и язык, и ресурсы (C++). Д а и что тут "другие"? Языков, требующих GC немало, они не ограничиваются Java/C#. Так вот, при этом ручное управление ресурсами одинаково хорошо реализовано и в С, и в C++, и в C#. Значит, у языков с GC есть некоторое преимущество.

С>Кстати, есть, на мой взгляд, как минимум одна область, где GC дает явное преимущество, а возможно и просто является необходимостью — многопоточные и асинхронные приложения. В свое время я набросал кое-что в блоге по этому поводу. А в библиотеке acto мне пришлось двухфазное удаление делать (так как в С++ нет GC). А все потому, что ссылки на объект могут находиться в другом потоке, или в какой-нибудь очереди сообщений и явное удаление просто обрушит программу...


Там в блоге практически ничего нет. По существу только — определение циклов. Но это проблема существовала и до многопоточности и асинхронности. И соотв. не имеет с ней ничего общего.
Решали же все проблему циклов. Первый вариант — не создавать циклов. Второй — создавать циклы, но с помощью weak_ptr, т.ч. не было сильных циклов. Третьий — вручную разрушать циклы, когда они перестают быть нужны. Я не вижу тут никакой связи ни с многопоточностью, ни с асинхронностью... за исключением того, что это становится немного сложнее...

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

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

M>>Мне кажется у тебя неверная предросылка, о том что С++ програмист управляет памятью.

AVK>Ну да, в шарпе проблема явно юзинг указать для детерминированного завершения, а явно использовать смартпоинтеры для любого класса и руками разруливать циклы, это конечно не проблема .


Хух... Последние полдня мучался, что бы использовать смарт-поинтер для одного объекта. Вроде получилось. Да... не лёгкое было дело. Надо будет ещё протестировать, корректно ли он использовался, или ошибся где-нибудь...

Завтра буду весь день заниматься организацией циклов объектов, т.ч. не поминайте лихом. Да... циклы объектов — это вообще беда... Пора браться за ум и отучаться от этого моветона...

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

E>>>Где GC может стать причиной остановки большого количества потоков для сборки мусора.
С>>Ведь есть же разные алгоритмы, необязательно все останавливать разом?!.. Ну и много ли имеется вариантов по данному вопросу? Когда произвольная схема многопоточности (каждый поток может взаимодействовать с любым другим), когда актеры могут произвольным образом между собой связываться и взаимодействовать... Вот как в такой системе управлять их временем жизни и при этом, по-возможности, не заставлять пользователя следить за этим самостоятельно?

R>А в чём проблема? Никаких отличий от использования обычного умного указателя, например shared_ptr, для пользователя не будет.
R>Банально shared_ptr может делать atomic_inc/atomic_dec для счётчика ссылок, либо применять какую-то более умную схему. Но это не важно с т.з. пользователя, т.к. для него будет тот же "smart_ptr", а уж что он там делает за кулисами — не касается пользователя.
R>Почему у тебя там возникли проблемы — не понимаю...
R>Погляди реализацию в SObjectizer — там, например, когда актёру посылается сообщение, для него инкрементируется счётчик, а когда обработка завершается — декрементируется.
Вот, как раз с сообщениями у меня проблем меньше всего. Но актеры не просто посылают сообщения друг другу, но и связи между собой устанавливают. Каждый актер хранит ссылку на самого себя, плюс пользователь еще может добавить парочку таких ссылок, а еще можно описать схему, где a->b->c->a, ну и еще кучу разнообразных вариантов... а еще все это может меняться динамически... И как в общем случае управлять таким графом актеров, но так, чтобы не рубить жестко связи (это не всегда подходит) и чтобы не забывать ненужное?

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

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

E>>>>Где GC может стать причиной остановки большого количества потоков для сборки мусора.
С>>>Ведь есть же разные алгоритмы, необязательно все останавливать разом?!.. Ну и много ли имеется вариантов по данному вопросу? Когда произвольная схема многопоточности (каждый поток может взаимодействовать с любым другим), когда актеры могут произвольным образом между собой связываться и взаимодействовать... Вот как в такой системе управлять их временем жизни и при этом, по-возможности, не заставлять пользователя следить за этим самостоятельно?

R>>А в чём проблема? Никаких отличий от использования обычного умного указателя, например shared_ptr, для пользователя не будет.
R>>Банально shared_ptr может делать atomic_inc/atomic_dec для счётчика ссылок, либо применять какую-то более умную схему. Но это не важно с т.з. пользователя, т.к. для него будет тот же "smart_ptr", а уж что он там делает за кулисами — не касается пользователя.
R>>Почему у тебя там возникли проблемы — не понимаю...
R>>Погляди реализацию в SObjectizer — там, например, когда актёру посылается сообщение, для него инкрементируется счётчик, а когда обработка завершается — декрементируется.
С>Вот, как раз с сообщениями у меня проблем меньше всего. Но актеры не просто посылают сообщения друг другу, но и связи между собой устанавливают.

С>Каждый актер хранит ссылку на самого себя,

не имеет значения

С>плюс пользователь еще может добавить парочку таких ссылок,

не имеет значения

С>а еще можно описать схему, где a->b->c->a,

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

С>ну и еще кучу разнообразных вариантов...

не имеет значения

С>а еще все это может меняться динамически...

не имеет значения

konsoletyper wrote:
> C>Это не совсем так — там просто нужна структура типа "веревка". На
> чистом С++ она тоже неплохо делается, причем даже работает вполне быстро
> Что это за структура?
http://en.wikipedia.org/wiki/Rope_%28computer_science%29

Sinclair wrote:
> E>Т.е. это нормальное решение, когда какая-то подсистема приложения
> дергает GC всего приложения для того, чтобы очистить свои ресурсы?
> Это — нет. По идее, у подсистемы должен быть свой независимый GC. Но
> такое щасте нам будет доступно только в 100%-managed OS.
Тогда другая проблема — все вызовы между доменами придется маршаллить.

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

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

E>>Где GC может стать причиной остановки большого количества потоков для сборки мусора.
С>Ведь есть же разные алгоритмы, необязательно все останавливать разом?!..

Я и не говорил про остановку всего разом. Но то что часть потоков будет одновременно приостановлена GC -- это факт. И в какой момент это произойдет заранее не известно.

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

Пользователю в любом случае придется как-то помечать уже не нужные ему актеры. Автор фреймворка должен будет только определиться с тем, как пользователь будет это делать: вызывать какой-нибудь deregister_actor или delete в C++, или занулять ссылку на актера в языке с GC. А остальное уже дело техники.

С>>>В свое время я набросал кое-что в блоге по этому поводу. А в библиотеке acto мне пришлось двухфазное удаление делать (так как в С++ нет GC).

E>>В связи с этим вопрос -- а зачем было делать библиотеку на C++?
С>Не на C++, а для С++... Приходится писать на C++, ну и хочется какого-то человеческого взаимодействия между потоками. Однажды мне пришлось делать небольшую программу, где была необходимость асинхронного взаимодействия между потоками, там я использовал Windows-очередь, но это уж как-то совсем неудобно мне показалось...

Как-то странно -- делать на C++ и вздыхать по поводу отсутствия GC

Здравствуйте, Cyberax, Вы писали:
C>Тогда другая проблема — все вызовы между доменами придется маршаллить.
Нда, я пожалуй погорячился.
Вообще, должно быть другое решение.
Идея решения примерно такова: при нехватке любого ресурса поток встает на ожидании освобождения; как только встали все потоки — единственный, кому можно работать, это GC и finalyzer thread. Ну то есть необязательно доводить совсем уж до упора, чем больше потоков тормознулось, тем выше шансы у GC запуститься.

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

S>Ну то есть необязательно доводить совсем уж до упора, чем больше потоков тормознулось, тем выше шансы у GC запуститься.

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

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

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

E>Пользователю в любом случае придется как-то помечать уже не нужные ему актеры. Автор фреймворка должен будет только определиться с тем, как пользователь будет это делать: вызывать какой-нибудь deregister_actor или delete в C++, или занулять ссылку на актера в языке с GC. А остальное уже дело техники.


смарт поинтер не рассматривается?