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

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

Vi2>

_>>Нигде не нашел информации. Как обеспечить interlocking при работе с ROT? Допустим, один процесс вызывает IMoniker::BindToObject, моникер лезет в IRunningObjectTable::GetObject и обнаруживает, что объекта там нет. Тогда он создает новый объект и вызывает для него Load. Внутри Load объект должен себя зарегистрить в ROT...

Vi2>Объект вообще не должен себя регистрировать в ROT — это не его задача. И дерегистрировать тоже. Это дело контейнера объекта (другими словами — его клиента).

Vi2>Это, действительно, туманное место для моникеров. Но к объекту никоим боком не относится — объект о РОТ ни сном ни духом.

Гм. Читаем в MSDN описание метода IPersistFile::Load ()
"When the object has been loaded, your implementation should register the object in the Running Object Table (see IRunningObjectTable::Register)."

Vi2>Моникер, ОТОН, тоже не обязан регистрировать объект в ROTе — у него есть для этого контекст. Но поиск в ROTе моникер делает, а регистрацию — нет.

Дык, это и так понятно. Не об этом вопрос.

Все это хорошо, но мне нужно практическое решение. Имеется сервер, реализующий COM объекты с уникальными именами. Нужно гарантировать создание только одного экземпляра объекта с определенным именем. Классическое решение — реализовать у объекта интерфейс IPersistFile и получать его экземпляр через File Moniker, в соответствии с описанным мной в первом постинге алгоритмом. Но как быть с многозадачностью?
Что делать-то? Не может быть, чтобы ни у кого не возникало подобной проблемы.