Нигде не нашел информации. Как обеспечить interlocking при работе с ROT? Допустим, один процесс вызывает IMoniker::BindToObject, моникер лезет в IRunningObjectTable::GetObject и обнаруживает, что объекта там нет. Тогда он создает новый объект и вызывает для него Load. Внутри Load объект должен себя зарегистрить в ROT. Что если другой процесс вызвал BindToObject для такого же моникера после того, как первый процесс обратился к GetObject, но до того, как он зарегистрировал новый объект в ROT? Создание одного экземпляра при этом не обеспечивается.
Даже если предположить, что внутри системных моникеров идет какая-то недокументированная блокировка, через мютекс например, все равно проблема не рещена. Когда обнулился счетчик ссылок объекта, он должен удалить себя из ROT. Что, если другой процесс вызовет GetObject после обнуления счетчика, но до того, как ссылка на объект удалена из ROT? Вот если бы я мог заблокировать таблицу каким-нибудь вызовом вроде IRunningObjectTable::Lock, потом опять проверить счетчик ссылок, если он все еще 0, удалить объект из ROT и разблокировать ее. Но ведь не могу?
В общем, ответа на этот вопрос в MSDN я так и не нашел. А вроде, он должен постоянно возникать? Может, кто чего знает?
_>Нигде не нашел информации. Как обеспечить interlocking при работе с ROT? Допустим, один процесс вызывает IMoniker::BindToObject, моникер лезет в IRunningObjectTable::GetObject и обнаруживает, что объекта там нет. Тогда он создает новый объект и вызывает для него Load. Внутри Load объект должен себя зарегистрить в ROT...
Объект вообще не должен себя регистрировать в ROT — это не его задача. И дерегистрировать тоже. Это дело контейнера объекта (другими словами — его клиента).
Это, действительно, туманное место для моникеров. Но к объекту никоим боком не относится — объект о РОТ ни сном ни духом.
Моникер, ОТОН, тоже не обязан регистрировать объект в ROTе — у него есть для этого контекст. Но поиск в ROTе моникер делает, а регистрацию — нет.
Здравствуйте, 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, в соответствии с описанным мной в первом постинге алгоритмом. Но как быть с многозадачностью?
Что делать-то? Не может быть, чтобы ни у кого не возникало подобной проблемы.
_>Гм. Читаем в MSDN описание метода IPersistFile::Load ()
_>"When the object has been loaded, your implementation should register the object in the Running Object Table (see IRunningObjectTable::Register)."
Не обращай внимания. Это относится к компаудным документам (реализующим IOleObject и т.п.) и к самому IPersistFile не имеет отношения. Потому как моникера регистрации нет. Да и требовать от этого интерфейса не свойственных ему функций — несуразица. Хотя для своих объектов это и можно сделать.
_>Все это хорошо, но мне нужно практическое решение. Имеется сервер, реализующий COM объекты с уникальными именами. Нужно гарантировать создание только одного экземпляра объекта с определенным именем. Классическое решение — реализовать у объекта интерфейс IPersistFile и получать его экземпляр через File Moniker, в соответствии с описанным мной в первом постинге алгоритмом. Но как быть с многозадачностью?
_>Что делать-то? Не может быть, чтобы ни у кого не возникало подобной проблемы.
А по-моему тут нет никакой проблемы. Регистрация в ROTе имеет одну ссылку на объект. Пока сам объект не захочет убраться из системы, ROT его будет держать. А кто уж его регистрит в ROT — это издержки проектирования. Главное — кто удалять будет!
Здравствуйте, Vi2, Вы писали:
Vi2>Здравствуйте, john_silver, Вы писали:
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>Не обращай внимания. Это относится к компаудным документам (реализующим IOleObject и т.п.) и к самому IPersistFile не имеет отношения. Потому как моникера регистрации нет. Да и требовать от этого интерфейса не свойственных ему функций — несуразица. Хотя для своих объектов это и можно сделать.
Я как-то привык обращать внимание на то, что написано в документации С чего ты взял "к самому IPersistFile не имеет отношения"??? Ну не надо фантазий про компаундные документы, они в рассматриваемом случае ни при чем
Вот тебе пример из MSDN, раздел "Monikers and Persistence", учи матчасть.
STDMETHODIMP Gorilla::Load(const OLECHAR *pszFileName,
DWORD grfMode) {
// read in persisted object state
HRESULT hr = this->MyReadStateFromFile(pszFile, grfMode);
if (FAILED(hr)) return hr;
// get pointer to ROT from SCM
IRunningObjectTable *prot = 0;
hr = GetRunningObjectTable(0, &prot);
if (SUCCEEDED(hr)) {
// create a file moniker to register in ROT
IMoniker *pmk = 0;
hr = CreateFileMoniker(pszFileName, &pmk);
if (SUCCEEDED(hr)) {
// register self in ROT
hr = prot->Register(0, this, pmk, &m_dwReg); pmk->Release();
} prot->Release();
}
return hr;
}
_>>Что делать-то? Не может быть, чтобы ни у кого не возникало подобной проблемы.[/q] Vi2>А по-моему тут нет никакой проблемы. Регистрация в ROTе имеет одну ссылку на объект.
Регистрация в ROT имеет сколько угодно ссылок на объекты с одним моникером.
Vi2>Пока сам объект не захочет убраться из системы, ROT его будет держать.
Это в случае strong reference (ROTFLAGS_REGISTRATIONKEEPSALIVE). Weak reference, которую я имел в виду, держать объект не будет.
Vi2>А кто уж его регистрит в ROT — это издержки проектирования. Главное — кто удалять будет!
Проблема с многозадачностью есть и при добавлении, и при удалении, причем, независимо от того, кто будет удалять. А вот решения не приведено, зачем трепаться тогда?
JS>Проблема с многозадачностью есть и при добавлении, и при удалении, причем, независимо от того, кто будет удалять.
А почему бы не воспользоваться примитивами синхронизации OS? Типа мьютексы?
С чего ты взял "к самому IPersistFile не имеет отношения"??? Ну не надо фантазий про компаундные документы, они в рассматриваемом случае ни при чем 
