Что делает CoLockObjectExternal?

На MSDN описание совершенно непонятное. А Don Box вообще описывает это совершенно по-другому(и тоже непонятно).

Опираясь на описание из MSDN, я не понимаю, чем это отличается от AddRef.
А уж тем более, как эта функция может каким-то волшебным образом "залочить" объект.

Добавлено через 1 час 14 минут
Если используете у себя эту функцию, прошу поделиться, для чего используете.

Очень желаю понять назначение этой функции.

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

0

Сообщение от Хрисипп Опираясь на описание из MSDN, я не понимаю, чем это отличается от AddRef. А уж тем более, как эта функция может каким-то волшебным образом "залочить" объект.

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

0

Сообщение от oleg-m1973 Насколько я понял, она ещё блокирует от выгрузки процесс, в котором был создан этот объект.

Но эту функцию же должен вызывать сам процесс, в котором этот объект находится.
Зачем ему это может быть нужно?

И тоже интересно. Как это вообще? Вот падает процесс, или вызывается TerminateProcess, или даже просто закрывается единственное окно программы -- что дальше, кто будет RPC вызовы выполнять? Ведь подразумевается, что процесс нужно держать в памяти для какого-то другого процесса?

0

Вот тут есть немного про эту функцию, может что прояснится: "Сущность технологии СОМ. Библиотека программиста". Пролистайте текст до вашей функции.

Я так понял, что это всё из области DCOM (Distributed COM) и как-то используется в контексте мониторинга за удалённым (от слова даль, а не удалить) объектом из стороннего процесса. Сам с этим не сталкивался, всё время использовал только объекты живущие в контексте приложения (CLSCTX_INPROC_SERVER), так что помощи от меня не много будет.

Добавлено через 6 секунд
Вот тут есть немного про эту функцию, может что прояснится: "Сущность технологии СОМ. Библиотека программиста". Пролистайте текст до вашей функции.

Я так понял, что это всё из области DCOM (Distributed COM) и как-то используется в контексте мониторинга за удалённым (от слова даль, а не удалить) объектом из стороннего процесса. Сам с этим не сталкивался, всё время использовал только объекты живущие в контексте приложения (CLSCTX_INPROC_SERVER), так что помощи от меня не много будет.

0

Сообщение от Хрисипп И тоже интересно. Как это вообще? Вот падает процесс, или вызывается TerminateProcess, или даже просто закрывается единственное окно программы -- что дальше, кто будет RPC вызовы выполнять? Ведь подразумевается, что процесс нужно держать в памяти для какого-то другого процесса?

Вряд ли кто-то рассчитывает что твой процесс будет падать или вызывать TerminateProcess. Нормальные процессы-серверы обычно так не делают.

0

Сообщение от oleg-m1973 Вряд ли кто-то рассчитывает что твой процесс будет падать или вызывать TerminateProcess.

А по какой еще причине может произойти "выгрузка процесса"?

0

Сообщение от Хрисипп А по какой еще причине может произойти "выгрузка процесса"?

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

0

---

0

Сообщение от oleg-m1973 Зачем тебе это вообще понадобилось?

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

0

Сообщение от Хрисипп А по какой еще причине может произойти "выгрузка процесса"?

А как у вас организован запуск серверного процесса и какое у него время жизни?

В DCOM инициатором создания серверного объекта может быть клиент. Шлётся запрос к серверу, сервер запускает процесс заглушку, который загружает DLL с нужным COM-объектом и создаёт его. Соответственно, если клиент отключится или релизнет объект, то на сервере процесс-заглушка удалит объект и сам выгрузится. Если это как-то так работает, то данная функция может предотвратить выгрузку серверного объекта при отключении от него клиентов.

0

Сообщение от Хрисипп Я работаю над проектом, в котором это используется. Проект довольно старый, используется COM широко, и уже никто не в курсе для чего вся эта дичь.

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

0

Сообщение от Ygg А как у вас организован запуск серверного процесса и какое у него время жизни?

Запуск из клиента или напрямую.

Сообщение от Ygg Если это как-то так работает, то данная функция может предотвратить выгрузку серверного объекта при отключении от него клиентов.

Да, видимо для этого почему-то тоже используется. Тогда не понятно -- а чем AddRef плох?

Еще CoLockObjectExternal используется в реализации IExternalConnection, но уже не для серверного объекта, а для некоторых других. Серверный объект тоже наследуется от IExternalConnection, но в AddConnection используется AddRef.

0

Сообщение от Хрисипп Да, видимо для этого почему-то тоже используется. Тогда не понятно -- а чем AddRef плох?

В той книге, на которую я раньше ссылался, на странице 18 немного рассказывается об администраторе заглушек.

(возможно, дальше будет полёт моей фантазии и он не очень соответствует реальности)
Как я понимаю, в некоторых случаях ваш объект получается размазан по нескольким местам. Во-первых, есть объект с вашей реализацией. Во-вторых, у пользователя объекта есть его прокси копия (заместитель). В-третьих, есть ещё заглушка, которая содержит в себе реальный объект с реализацией (1) и обеспечивает его взаимодействие с заместителями (2). Заместители и заглушки получаются автоматически, это не ваш код, а среда исполнения COM. AddRef вы можете сделать только из пользовательской программы или из реализации объекта. Вызов из пользовательской программы естественно увеличит счётчик и предотвратит выгрузку. Но вас интересует вызов из реализации, а он лишь выполнит увеличение локального счётчика ссылок. Администратор заглушек про него ничего знать не знает и ему на него по большому счёту плевать. У него свой счётчик, основанный на заместителях. Поэтому, когда последний заместитель вызовет релиз, администратор самоудалится вместе с объектом. Вот как раз что бы избежать этого, реализация может вызвать эту самую CoLockObjectExternal.

0

Сообщение от Ygg Поэтому, когда последний заместитель вызовет релиз, администратор самоудалится вместе с объектом.

Ну как же с объектом. Администратор же вызовет Release у объекта, а у нас будет оставаться еще одна ссылка(AddRef из реализации), и никуда объект не денется. Так ведь?

0

Сообщение от Хрисипп Ну как же с объектом. Администратор же вызовет Release у объекта, а у нас будет оставаться еще одна ссылка(AddRef из реализации), и никуда объект не денется. Так ведь?

Это уже вопрос устройства администратора. Если администратор интегрирован в пользовательский процесс, то, скорее всего, именно так, как вы говорите, объект останется живым. Если же администратор является отдельным процессом, то время его жизни закончилось и вместе с его закрытием умрут все объекты и потоки. Плюсом к этому могут идти какие-нибудь хитрые связки различных объектов, когда релиз одного приводит к релизу связанных с ним. В документации msdn в описании функции что-то говорилось про использовании с OLE-контейнерами, но я там не сильно что-то понял. Короче, по правильному получается на критическую работу внутри объекта, если она не должна прерываться внешним релизом, лучше сделать блокировку CoLockObjectExternal, а не AddRef. После завершения критической обработки разблокировать тем же CoLockObjectExternal, что запустит штатную процедуру удаления объекта.

0

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

Что-то я не понимаю. Как это объекты умрут? Объект же нельзя просто уничтожить(по крайней мере вне реализации). Все вне реализации могут сделать либо AddRef, либо Release. Или я чего-то не понимаю?

0

Сообщение от Хрисипп Что-то я не понимаю. Как это объекты умрут? Объект же нельзя просто уничтожить(по крайней мере вне реализации). Все вне реализации могут сделать либо AddRef, либо Release. Или я чего-то не понимаю?

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

Добавлено через 2 минуты
Там по ссылке приведён пример с методами StartMonotor/StopMonitor. Эти методы могут вызываться один утром, второй завтра. Между вызовами ними никаких обращений к серверу не будет, т.е. система запросто может решить, что сервер не используется и его можно погасить.

0

Сообщение от oleg-m1973 В некоторых конечный, удалённый, объект может быть закрыт, когда к нему долго нет обращения.

Так а как это произойдет, если имеется еще лишний AddRef(вызванный из реализации)?

Сообщение от oleg-m1973 система запросто может решить, что сервер не используется и его можно погасить.

Типа TerminateProcess сделать? Или как? Каким образом "погасить"?

0

Сообщение от Хрисипп Так а как это произойдет, если имеется еще лишний AddRef(вызванный из реализации)?

Этот AddRef вызывается на клиенте. До сервера там довольно далеко.

0

Сообщение от oleg-m1973 Этот AddRef вызывается на клиенте. До сервера там довольно далеко.

Почему на клиенте?
Речь же идет о том, чтобы заменить вызов CoLockObjectExternal на AddRef, т.е. на сервере.
CoLockObjectExternal можно же вызвать только на сервере(где объект был создан/обитает).

0