Что делает CoLockObjectExternal?

@Хрисипп · Регистрация: 09.02.2016

Author24 — интернет-сервис помощи студентам

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

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

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

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

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

@oleg-m1973 · 10.09.2020, 11:22

Сообщение от Хрисипп

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

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

@Хрисипп · 10.09.2020, 13:16 **[ТС]**

Сообщение от oleg-m1973

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

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

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

@Ygg · 10.09.2020, 13:38

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

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

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

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

@oleg-m1973 · 10.09.2020, 16:31

Сообщение от Хрисипп

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

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

@Хрисипп · 10.09.2020, 16:49 **[ТС]**

Сообщение от oleg-m1973

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

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

@oleg-m1973 · 10.09.2020, 16:56

Сообщение от Хрисипп

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

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

@Ygg · 10.09.2020, 17:09

---

@Хрисипп · 10.09.2020, 17:11 **[ТС]**

Сообщение от oleg-m1973

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

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

@Ygg · 10.09.2020, 17:22

Сообщение от Хрисипп

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

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

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

@oleg-m1973 · 10.09.2020, 17:44

Сообщение от Хрисипп

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

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

@Хрисипп · 10.09.2020, 17:48 **[ТС]**

Сообщение от Ygg

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

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

Сообщение от Ygg

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

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

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

@Ygg · 10.09.2020, 18:31

Сообщение от Хрисипп

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

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

Цитата от туда

Между администраторами заглушек и идентификационными единицами СОМ-объектов имеется взаимно однозначное соответствие. Каждый администратор заглушек ссылается на ровно один СОМ-объект. Каждый СОМ-объект, использующий стандартный маршалинг, будет иметь ровно один администратор заглушек. Администратор заглушек содержит но крайней мере одну неосвобожденную ссылку на объект, которая удерживает ресурсы объекта в памяти. В этом смысле администратор заглушек является еще одним внутрипроцессным клиентом для объекта. Администратор заглушек следит за числом неосвобожденных внешних ссылок и будет существовать до тех пор, пока где-либо в сети останется хотя бы одна неосвобожденная ссылка. Большинство внешних ссылок являются просто заместителями, хотя промежуточные маршалированные объектные ссылки могут удерживать заглушки, чтобы быть уверенными, что в момент создания первого заместителя объект еще существует. Когда неосвобожденные заместители или ссылки уничтожаются, администратор заглушек извещается об этом и декрементирует свой счетчик внешних ссылок. Если уничтожена последняя внешняя ссылка на администратор заглушек, то последний самоуничтожается, освобождая свои неосвобожденные ссылки на действующий объект. Это имитирует эффект наличия на стороне клиента ссылок, поддерживающих объект.

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

@Хрисипп · 10.09.2020, 19:12 **[ТС]**

Сообщение от Ygg

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

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

@Ygg · 10.09.2020, 19:40

Сообщение от Хрисипп

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

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

@Хрисипп · 10.09.2020, 20:05 **[ТС]**

Сообщение от Ygg

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

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

@oleg-m1973 · 10.09.2020, 20:18

Сообщение от Хрисипп

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

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

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

@Хрисипп · 10.09.2020, 20:36 **[ТС]**

Сообщение от oleg-m1973

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

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

Сообщение от oleg-m1973

система запросто может решить, что сервер не используется и его можно погасить.

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

@oleg-m1973 · 10.09.2020, 20:37

Сообщение от Хрисипп

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

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

@Хрисипп · 10.09.2020, 20:44 **[ТС]**

Сообщение от oleg-m1973

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

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

Новые блоги и статьи Все статьи Все блоги /
Компиляция C++ с Clang API NullReferenced 24.03.2025 Компиляторы обычно воспринимаются как черные ящики, которые превращают исходный код в исполняемые файлы. Мы запускаем компилятор командой в терминале, и вуаля — получаем бинарник. Но что если нужно. . .	Многопоточное программирование в C#: Класс Thread UnmanagedCoder 24.03.2025 Когда запускается приложение на компьютере, операционная система создаёт для него процесс - виртуальное адресное пространство. В C# этот процесс изначально получает один поток выполнения — главный. . .	SwiftUI Data Flow: Передача данных между представлениями mobDevWorks 23.03.2025 При первом знакомстве со SwiftUI кажется, что фреймворк предлагает избыточное количество механизмов для передачи данных: @State, @Binding, @StateObject, @ObservedObject, @EnvironmentObject и другие. . . .	Моки в Java: Сравниваем Mockito, EasyMock, JMockit Javaican 23.03.2025 Как протестировать класс, который зависит от других сложных компонентов, таких как базы данных, веб-сервисы или другие классы, с которыми и так непросто работать в тестовом окружении? Для этого и. . .	Архитектурные паттерны микросервисов: ТОП-10 шаблонов ArchitectMsa 22.03.2025 Популярность микросервисной архитектуры объясняется множеством важных преимуществ. К примеру, она позволяет командам разработчиков работать независимо друг от друга, используя различные технологии и. . .
Оптимизация рендеринга в Unity: Сортировка миллиона спрайтов GameUnited 22.03.2025 Помните, когда наличие сотни спрайтов в игре приводило к существенному падению производительности? Время таких ограничений уходит в прошлое. Сегодня геймдев сталкивается с задачами совершенно иного. . .	Образование и практика Igor3D 21.03.2025 Добрый день А вот каково качество/ эффективность ВУЗовского образования? Аналитическая геометрия изучается в первом семестре и считается довольно легким курсом, что вполне справедливо. Ну хорошо,. . .	Lazarus. Таблица с объединением ячеек. Massaraksh7 21.03.2025 Понадобилась представление на экране таблицы с объединёнными ячейками. И не одной, а штук триста, и все разные. На Delphi я использовал для этих целей TStringGrid, и то, кривовато получалось. А в. . .	Async/await в Swift: Асинхронное программирование в iOS mobDevWorks 20.03.2025 Асинхронное программирование долго было одной из самых сложных задач для разработчиков iOS. В течение многих лет мы сражались с замыканиями, диспетчеризацией очередей и обратными вызовами, чтобы. . .	Колмогоровская сложность: Приёмы упрощения кода ArchitectMsa 20.03.2025 Наверное, каждый программист хотя бы раз сталкивался с кодом, который напоминает запутанный лабиринт — чем дальше в него погружаешься, тем сложнее найти выход. И когда мы говорим о сложности кода, мы. . .

@Хрисипп 19 / 29 / 13 Регистрация: 09.02.2016 Сообщений: 230

	Что делает CoLockObjectExternal? 09.09.2020, 22:24. Показов 39066. Ответов 23 Метки нет (Все метки) На MSDN описание совершенно непонятное. А Don Box вообще описывает это совершенно по-другому(и тоже непонятно). Опираясь на описание из MSDN, я не понимаю, чем это отличается от AddRef. А уж тем более, как эта функция может каким-то волшебным образом "залочить" объект. Добавлено через 1 час 14 минут Если используете у себя эту функцию, прошу поделиться, для чего используете. Очень желаю понять назначение этой функции. Надеюсь гуру откликнутся. 0

@oleg-m1973 6770 / 4564 / 1843 Регистрация: 07.05.2019 Сообщений: 13,726
	10.09.2020, 11:22
	Сообщение от Хрисипп Опираясь на описание из MSDN, я не понимаю, чем это отличается от AddRef. А уж тем более, как эта функция может каким-то волшебным образом "залочить" объект. Насколько я понял, она ещё блокирует от выгрузки процесс, в котором был создан этот объект. Или что-то типа того. 0

@Хрисипп 19 / 29 / 13 Регистрация: 09.02.2016 Сообщений: 230
	10.09.2020, 13:16 [ТС]
	Сообщение от oleg-m1973 Насколько я понял, она ещё блокирует от выгрузки процесс, в котором был создан этот объект. Но эту функцию же должен вызывать сам процесс, в котором этот объект находится. Зачем ему это может быть нужно? И тоже интересно. Как это вообще? Вот падает процесс, или вызывается TerminateProcess, или даже просто закрывается единственное окно программы -- что дальше, кто будет RPC вызовы выполнять? Ведь подразумевается, что процесс нужно держать в памяти для какого-то другого процесса? 0

@Ygg 2715 / 869 / 328 Регистрация: 10.02.2018 Сообщений: 2,059
	10.09.2020, 13:38
	Вот тут есть немного про эту функцию, может что прояснится: "Сущность технологии СОМ. Библиотека программиста". Пролистайте текст до вашей функции. Я так понял, что это всё из области DCOM (Distributed COM) и как-то используется в контексте мониторинга за удалённым (от слова даль, а не удалить) объектом из стороннего процесса. Сам с этим не сталкивался, всё время использовал только объекты живущие в контексте приложения (CLSCTX_INPROC_SERVER), так что помощи от меня не много будет. Добавлено через 6 секунд Вот тут есть немного про эту функцию, может что прояснится: "Сущность технологии СОМ. Библиотека программиста". Пролистайте текст до вашей функции. Я так понял, что это всё из области DCOM (Distributed COM) и как-то используется в контексте мониторинга за удалённым (от слова даль, а не удалить) объектом из стороннего процесса. Сам с этим не сталкивался, всё время использовал только объекты живущие в контексте приложения (CLSCTX_INPROC_SERVER), так что помощи от меня не много будет. 0

@oleg-m1973 6770 / 4564 / 1843 Регистрация: 07.05.2019 Сообщений: 13,726
	10.09.2020, 16:31
	Сообщение от Хрисипп И тоже интересно. Как это вообще? Вот падает процесс, или вызывается TerminateProcess, или даже просто закрывается единственное окно программы -- что дальше, кто будет RPC вызовы выполнять? Ведь подразумевается, что процесс нужно держать в памяти для какого-то другого процесса? Вряд ли кто-то рассчитывает что твой процесс будет падать или вызывать TerminateProcess. Нормальные процессы-серверы обычно так не делают. 0

@Хрисипп 19 / 29 / 13 Регистрация: 09.02.2016 Сообщений: 230
	10.09.2020, 16:49 [ТС]
	Сообщение от oleg-m1973 Вряд ли кто-то рассчитывает что твой процесс будет падать или вызывать TerminateProcess. А по какой еще причине может произойти "выгрузка процесса"? 0

@oleg-m1973 6770 / 4564 / 1843 Регистрация: 07.05.2019 Сообщений: 13,726
	10.09.2020, 16:56
	Сообщение от Хрисипп А по какой еще причине может произойти "выгрузка процесса"? Скорее всего, процесс тупо не будет завершаться, пока кто-то ссылается на объекты, созданные в нём. Но, я тоже слабо в этом разбираюсь. Зачем тебе это вообще понадобилось? В большинстве случаев безо всего этого можно обойтись. 0

@Ygg 2715 / 869 / 328 Регистрация: 10.02.2018 Сообщений: 2,059
	10.09.2020, 17:09
	--- 0

@Хрисипп 19 / 29 / 13 Регистрация: 09.02.2016 Сообщений: 230
	10.09.2020, 17:11 [ТС]
	Сообщение от oleg-m1973 Зачем тебе это вообще понадобилось? Я работаю над проектом, в котором это используется. Проект довольно старый, используется COM широко, и уже никто не в курсе для чего вся эта дичь. 0

@Ygg 2715 / 869 / 328 Регистрация: 10.02.2018 Сообщений: 2,059
	10.09.2020, 17:22
	Сообщение от Хрисипп А по какой еще причине может произойти "выгрузка процесса"? А как у вас организован запуск серверного процесса и какое у него время жизни? В DCOM инициатором создания серверного объекта может быть клиент. Шлётся запрос к серверу, сервер запускает процесс заглушку, который загружает DLL с нужным COM-объектом и создаёт его. Соответственно, если клиент отключится или релизнет объект, то на сервере процесс-заглушка удалит объект и сам выгрузится. Если это как-то так работает, то данная функция может предотвратить выгрузку серверного объекта при отключении от него клиентов. 0

Опции темы

@oleg-m1973 6770 / 4564 / 1843 Регистрация: 07.05.2019 Сообщений: 13,726
	10.09.2020, 17:44
	Сообщение от Хрисипп Я работаю над проектом, в котором это используется. Проект довольно старый, используется COM широко, и уже никто не в курсе для чего вся эта дичь. В общем, это сервер не даёт выгрузить себя из памяти, завершить свой процесс. Если у тебя это уже сделано, то просто не заморачивайся, оставь. 0

@Хрисипп 19 / 29 / 13 Регистрация: 09.02.2016 Сообщений: 230
	10.09.2020, 17:48 [ТС]
	Сообщение от Ygg А как у вас организован запуск серверного процесса и какое у него время жизни? Запуск из клиента или напрямую. Сообщение от Ygg Если это как-то так работает, то данная функция может предотвратить выгрузку серверного объекта при отключении от него клиентов. Да, видимо для этого почему-то тоже используется. Тогда не понятно -- а чем `AddRef` плох? Еще `CoLockObjectExternal` используется в реализации `IExternalConnection`, но уже не для серверного объекта, а для некоторых других. Серверный объект тоже наследуется от `IExternalConnection`, но в `AddConnection` используется `AddRef`. 0

@Ygg 2715 / 869 / 328 Регистрация: 10.02.2018 Сообщений: 2,059
	10.09.2020, 18:31
	Сообщение от Хрисипп Да, видимо для этого почему-то тоже используется. Тогда не понятно -- а чем AddRef плох? В той книге, на которую я раньше ссылался, на странице 18 немного рассказывается об администраторе заглушек. Цитата от туда Между администраторами заглушек и идентификационными единицами СОМ-объектов имеется взаимно однозначное соответствие. Каждый администратор заглушек ссылается на ровно один СОМ-объект. Каждый СОМ-объект, использующий стандартный маршалинг, будет иметь ровно один администратор заглушек. Администратор заглушек содержит но крайней мере одну неосвобожденную ссылку на объект, которая удерживает ресурсы объекта в памяти. В этом смысле администратор заглушек является еще одним внутрипроцессным клиентом для объекта. Администратор заглушек следит за числом неосвобожденных внешних ссылок и будет существовать до тех пор, пока где-либо в сети останется хотя бы одна неосвобожденная ссылка. Большинство внешних ссылок являются просто заместителями, хотя промежуточные маршалированные объектные ссылки могут удерживать заглушки, чтобы быть уверенными, что в момент создания первого заместителя объект еще существует. Когда неосвобожденные заместители или ссылки уничтожаются, администратор заглушек извещается об этом и декрементирует свой счетчик внешних ссылок. Если уничтожена последняя внешняя ссылка на администратор заглушек, то последний самоуничтожается, освобождая свои неосвобожденные ссылки на действующий объект. Это имитирует эффект наличия на стороне клиента ссылок, поддерживающих объект. (возможно, дальше будет полёт моей фантазии и он не очень соответствует реальности) Как я понимаю, в некоторых случаях ваш объект получается размазан по нескольким местам. Во-первых, есть объект с вашей реализацией. Во-вторых, у пользователя объекта есть его прокси копия (заместитель). В-третьих, есть ещё заглушка, которая содержит в себе реальный объект с реализацией (1) и обеспечивает его взаимодействие с заместителями (2). Заместители и заглушки получаются автоматически, это не ваш код, а среда исполнения COM. AddRef вы можете сделать только из пользовательской программы или из реализации объекта. Вызов из пользовательской программы естественно увеличит счётчик и предотвратит выгрузку. Но вас интересует вызов из реализации, а он лишь выполнит увеличение локального счётчика ссылок. Администратор заглушек про него ничего знать не знает и ему на него по большому счёту плевать. У него свой счётчик, основанный на заместителях. Поэтому, когда последний заместитель вызовет релиз, администратор самоудалится вместе с объектом. Вот как раз что бы избежать этого, реализация может вызвать эту самую CoLockObjectExternal. 0

@Хрисипп 19 / 29 / 13 Регистрация: 09.02.2016 Сообщений: 230
	10.09.2020, 19:12 [ТС]
	Сообщение от Ygg Поэтому, когда последний заместитель вызовет релиз, администратор самоудалится вместе с объектом. Ну как же с объектом. Администратор же вызовет Release у объекта, а у нас будет оставаться еще одна ссылка(AddRef из реализации), и никуда объект не денется. Так ведь? 0

@Ygg 2715 / 869 / 328 Регистрация: 10.02.2018 Сообщений: 2,059
	10.09.2020, 19:40
	Сообщение от Хрисипп Ну как же с объектом. Администратор же вызовет Release у объекта, а у нас будет оставаться еще одна ссылка(AddRef из реализации), и никуда объект не денется. Так ведь? Это уже вопрос устройства администратора. Если администратор интегрирован в пользовательский процесс, то, скорее всего, именно так, как вы говорите, объект останется живым. Если же администратор является отдельным процессом, то время его жизни закончилось и вместе с его закрытием умрут все объекты и потоки. Плюсом к этому могут идти какие-нибудь хитрые связки различных объектов, когда релиз одного приводит к релизу связанных с ним. В документации msdn в описании функции что-то говорилось про использовании с OLE-контейнерами, но я там не сильно что-то понял. Короче, по правильному получается на критическую работу внутри объекта, если она не должна прерываться внешним релизом, лучше сделать блокировку CoLockObjectExternal, а не AddRef. После завершения критической обработки разблокировать тем же CoLockObjectExternal, что запустит штатную процедуру удаления объекта. 0

@Хрисипп 19 / 29 / 13 Регистрация: 09.02.2016 Сообщений: 230
	10.09.2020, 20:05 [ТС]
	Сообщение от Ygg Если же администратор является отдельным процессом, то время его жизни закончилось и вместе с его закрытием умрут все объекты и потоки. Что-то я не понимаю. Как это объекты умрут? Объект же нельзя просто уничтожить(по крайней мере вне реализации). Все вне реализации могут сделать либо AddRef, либо Release. Или я чего-то не понимаю? 0

@oleg-m1973 6770 / 4564 / 1843 Регистрация: 07.05.2019 Сообщений: 13,726
	10.09.2020, 20:18
	Сообщение от Хрисипп Что-то я не понимаю. Как это объекты умрут? Объект же нельзя просто уничтожить(по крайней мере вне реализации). Все вне реализации могут сделать либо AddRef, либо Release. Или я чего-то не понимаю? Ты забываешь, что DCOM это распределённая система. Объекты могут существовать не только в разных процессах, но и на разных машинах. Сценариев взаимодействия между ними, поддержки коннекта и т.д., довольно много. В некоторых конечный, удалённый, объект может быть закрыт, когда к нему долго нет обращения. Чтобы это предотвратить сервер блокирует себя. Добавлено через 2 минуты Там по ссылке приведён пример с методами StartMonotor/StopMonitor. Эти методы могут вызываться один утром, второй завтра. Между вызовами ними никаких обращений к серверу не будет, т.е. система запросто может решить, что сервер не используется и его можно погасить. 0

@Хрисипп 19 / 29 / 13 Регистрация: 09.02.2016 Сообщений: 230
	10.09.2020, 20:36 [ТС]
	Сообщение от oleg-m1973 В некоторых конечный, удалённый, объект может быть закрыт, когда к нему долго нет обращения. Так а как это произойдет, если имеется еще лишний AddRef(вызванный из реализации)? Сообщение от oleg-m1973 система запросто может решить, что сервер не используется и его можно погасить. Типа TerminateProcess сделать? Или как? Каким образом "погасить"? 0

@oleg-m1973 6770 / 4564 / 1843 Регистрация: 07.05.2019 Сообщений: 13,726
	10.09.2020, 20:37
	Сообщение от Хрисипп Так а как это произойдет, если имеется еще лишний AddRef(вызванный из реализации)? Этот AddRef вызывается на клиенте. До сервера там довольно далеко. 0

@Хрисипп 19 / 29 / 13 Регистрация: 09.02.2016 Сообщений: 230
	10.09.2020, 20:44 [ТС]
	Сообщение от oleg-m1973 Этот AddRef вызывается на клиенте. До сервера там довольно далеко. Почему на клиенте? Речь же идет о том, чтобы заменить вызов `CoLockObjectExternal` на `AddRef`, т.е. на сервере. `CoLockObjectExternal` можно же вызвать только на сервере(где объект был создан/обитает). 0