Здравствуйте, maxgora, Вы писали:
M>Столкнулся со следующей проблемой. M>Есть dll, содержащая класс со статическим объектом и приложение, M>использующее класс из dll. Если одновременно запустить несколько копий приложения, то у каждого приложения будет свой статический объект в классе из dll. Можно ли сделать так, чтобы некий объект из dll был общим для разных приложений (процессов)? M>(Среда VS2008, dll — на net compact fw 3.5, приложение — на net fw 3.5)
Используйте remoting. Создайте сервер экспортирующий стэйтлес-объект и подключайте к нему отдельные приложения-клиенты.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Использование одной dll в разных процессах.
S_B>Но возращаясь к длл. Мне кажется, что я где — то слышал, что длл с shared segment при каких-то настройках приложения всё-таки будет дублироваться. Это так?
Вообще это хак. Хак на побочных возможностях архитектуры. Плохо!
Зависит даже от ОС (у серверной приоритет фоновых процессов и все такое) и режима использования. Если винда решит что ей памяти маловато и решит поиграть в свопе, то шаред dll вполне могут быть запущены в двух разных экземплярах для двух разных процессов.
Это наследие очень древней истории ядра NT, когда памяти было мало, а файлов dll было много. Шаред режим был придуман чтобы не грузить одну и туже станд. либу для каждого из 20-ти процессов в 20-ти экземплярах. Но потом появилась проблема dll hell, и далее мем фатальный недостаток
Сейчас, на многоядрёных процессорах и гагабайтах оперативки словить клин шансов мало, но если у тебя сервак на пределе... Ну начнет вырубать некоторые процессы в своп — и им отдельная песочница.
Механизм шаринга dll по-моему не менялся с седых времен W2K, он стар как кости мамонта, а на него сверху теперь наложились еще и аппаратные механизмы виртуализации в самих процессорах.
Как эта штука сейчас работает сложно сказать. Я лично давно эту тему не разбирал, возможно есть какой-то хак для поддержки устаревших приложений, майкрософт даже прямо в код ядра бывает такие хаки вставляет даже для популярных игр (идентификиция процесса, и ему особый режим работы с памятью. пруф найду если надо, был)
Хочу инвайт на хабру :)
Re[6]: Использование одной dll в разных процессах.
Здравствуйте, enCobalt, Вы писали:
S_B>>Но возращаясь к длл. Мне кажется, что я где — то слышал, что длл с shared segment при каких-то настройках приложения всё-таки будет дублироваться. Это так? "Run in separate memory space" или что — то такое...
C>+Еще, если утешит.. Само собой не пройдешь сертификацию Windows Logo (это типа значек такой "Compatible with Windows ZZ"), сразу в разделе "Restart Manager API" — такой хак это фейлы по всем тестам без вариантов.
А можно ссылку на то, что это хак ? И на то, что shared секции могут при каких-то условиях стать не shared ?
А то ведь официальное руководство (MSDN) говорит (выделено мной — PD)
S Shared Shares the section among all processes that load the image
Столкнулся со следующей проблемой.
Есть dll, содержащая класс со статическим объектом и приложение,
использующее класс из dll. Если одновременно запустить несколько копий приложения, то у каждого приложения будет свой статический объект в классе из dll. Можно ли сделать так, чтобы некий объект из dll был общим для разных приложений (процессов)?
(Среда VS2008, dll — на net compact fw 3.5, приложение — на net fw 3.5)
Здравствуйте, maxgora, Вы писали:
M>Столкнулся со следующей проблемой. M>Есть dll, содержащая класс со статическим объектом и приложение, M>использующее класс из dll. Если одновременно запустить несколько копий приложения, то у каждого приложения будет свой статический объект в классе из dll. Можно ли сделать так, чтобы некий объект из dll был общим для разных приложений (процессов)? M>(Среда VS2008, dll — на net compact fw 3.5, приложение — на net fw 3.5)
Именно так как вы описали сделать нельзя.
Расскажите плз подробнее, какая бизнес задача решается.
Re[2]: Использование одной dll в разных процессах.
R>Расскажите плз подробнее, какая бизнес задача решается.
Dll реализует доступ к устройству ч/з COM порт (реальный или виртуальный) по протоколу modbus. Возможны варианты: работа с одним/несколькими устройствами ч/з мост bluetooth/usb, работа с несколькими ус-вами ч/з один (у-ва на шине RS485) или несколько портов. Предусмотрено переподключение (на случай работы ч/з bluetooth). Все работает в случае, если приложение — один процесс.
Возникла проблема по след. причине. Для адаптации работы со старым ПО, написана "обертка", позволяющая использовать часть функционала dll. Запускается старое ПО, все работает. Но еще хочется иметь возможность менять кое-какие параметры (расширенный функционал), не прерывая работу основной программы.
Реализация доступа к порту следующая. В классе объявлен статический ArrayList, содержащий список используемых портов. В конструкторе список проверяется и, если порт уже подключен — работаю ч/з него (разделение доступа), если нет — новое подключение. В случае обращения к конструктору из разных процессов разделение доступа не происходит, т.к. конструктор каждый раз пытается создать новое подключение.
или сейчас на WCF есть, чуть погибчее, там почти аналогично,
с параметрами только поиграться типа:
[InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Multiple]
При желании, времени и азарте можно даже трехзвенную кластерную инстанс-машину сделать с
балансировкой нагрузки, но правда это уже самому копать лопатой такой личный "фреймворк" под
свою задачу.
Хочу инвайт на хабру :)
Re[2]: Использование одной dll в разных процессах.
Здравствуйте, maxgora, Вы писали:
M>Столкнулся со следующей проблемой. M>Есть dll, содержащая класс со статическим объектом и приложение, M>использующее класс из dll. Если одновременно запустить несколько копий приложения, то у каждого приложения будет свой статический объект в классе из dll. Можно ли сделать так, чтобы некий объект из dll был общим для разных приложений (процессов)? M>(Среда VS2008, dll — на net compact fw 3.5, приложение — на net fw 3.5)
Мы тоже это используем. Но сейчас решал задачу межпроцессного взаимодействия, искал в интернете, и почему-то для NET этот вариант даже не предлагают. Предлагают WM_SENDDATA, трубы, слоты, евенты, маппинг файла в память, переменные среды окружения, но не это. Почему? Есть какие-то подводные камни?
Сергей
Re[3]: Использование одной dll в разных процессах.
Здравствуйте, Sergey_BG, Вы писали:
S_B>Мы тоже это используем. Но сейчас решал задачу межпроцессного взаимодействия, искал в интернете, и почему-то для NET этот вариант даже не предлагают. Предлагают WM_SENDDATA, трубы, слоты, евенты, маппинг файла в память, переменные среды окружения, но не это. Почему? Есть какие-то подводные камни?
Вообще от задачи зависит. Если у тебя что-то близкое к реалтайму, или игровое приложение — выглядит отлично. Но с учетом современных процов, шины, скорости памяти — глупо в большинстве. Гораздо чаще (со временем) встают задачи масштабироваться. Гораздо чаще чем ПО тормозит из-за межпроцессного общения.
И выходит что лучше родной ремотинг или wcf — если сервак "приперло" то просто разносишь процессы на два разных сервака и *trollface* А пока не приперло и работает на одной машине меняешь в конфиге протокол на napped pipe — он действительно быстрый.
Хочу инвайт на хабру :)
Re[4]: Использование одной dll в разных процессах.
Здравствуйте, enCobalt, Вы писали:
C>Вообще от задачи зависит.
Я сейчас так и сделал. Просто чтоб оценить трудности коммуникации посредством трубы.
Но так как задача не реал тайм. Процессор улучшается, ядра и память растут. То больше интересует простота. А реализация длл с shared segment проще, так как вся логика реализуется в одном месте.
Но возращаясь к длл. Мне кажется, что я где — то слышал, что длл с shared segment при каких-то настройках приложения всё-таки будет дублироваться. Это так? "Run in separate memory space" или что — то такое...
Сергей
Re[3]: Использование одной dll в разных процессах.
Здравствуйте, Sergey_BG, Вы писали:
S_B>Мы тоже это используем. Но сейчас решал задачу межпроцессного взаимодействия, искал в интернете, и почему-то для NET этот вариант даже не предлагают. Предлагают WM_SENDDATA, трубы, слоты, евенты, маппинг файла в память, переменные среды окружения, но не это. Почему? Есть какие-то подводные камни?
Подводных камней быть ИМХО не должно,так как этот механизм лежит ниже дотнета.
Почему не предлагают — сказать сложно. Во-первых, тут все же unmanaged C++, а он для многих дотнетчиков terra incognita и пугает их. А может, просто не знают.
With best regards
Pavel Dvorkin
Re[5]: Использование одной dll в разных процессах.
S_B>Но возращаясь к длл. Мне кажется, что я где — то слышал, что длл с shared segment при каких-то настройках приложения всё-таки будет дублироваться. Это так? "Run in separate memory space" или что — то такое...
+Еще, если утешит.. Само собой не пройдешь сертификацию Windows Logo (это типа значек такой "Compatible with Windows ZZ"), сразу в разделе "Restart Manager API" — такой хак это фейлы по всем тестам без вариантов.
Хочу инвайт на хабру :)
Re[5]: Использование одной dll в разных процессах.
Здравствуйте, Sergey_BG, Вы писали:
S_B>Но возращаясь к длл. Мне кажется, что я где — то слышал, что длл с shared segment при каких-то настройках приложения всё-таки будет дублироваться. Это так? "Run in separate memory space" или что — то такое...
Могу привести такой пример — dll с разделяемой секцией загружается в процессы, принадлежащие
разным пользовательским сессиям. Тогда получим несколько экземпляров shared-секции.
Re[6]: Использование одной dll в разных процессах.
Здравствуйте, enCobalt, Вы писали:
C>Вообще это [длл с shared segment] хак. Хак на побочных возможностях архитектуры. Плохо!
Это не хак, а заложенная в архитектуре возможность, которая ничем не хуже других.
Разделяемые секции в Win32 реализованы посредством file mapping objects (читай — того же MMF) и
опирается на известные аппаратные свойства x86, благодаря чему, например, в каждом адресном
пространстве доступны общие системные библиотеки вроде kernel32, при том, что физически загружена
только одна копия каждой.
C>Зависит даже от ОС (у серверной приоритет фоновых процессов и все такое) и режима использования. Если винда решит что ей памяти маловато и решит поиграть в свопе, то шаред dll вполне могут быть запущены в двух разных экземплярах для двух разных процессов.
C>Это наследие очень древней истории ядра NT, когда памяти было мало, а файлов dll было много. Шаред режим был придуман чтобы не грузить одну и туже станд. либу для каждого из 20-ти процессов в 20-ти экземплярах. Но потом появилась проблема dll hell, и далее мем фатальный недостаток
C>Сейчас, на многоядрёных процессорах и гагабайтах оперативки словить клин шансов мало, но если у тебя сервак на пределе... Ну начнет вырубать некоторые процессы в своп — и им отдельная песочница. C>Механизм шаринга dll по-моему не менялся с седых времен W2K, он стар как кости мамонта, а на него сверху теперь наложились еще и аппаратные механизмы виртуализации в самих процессорах.
Может быть, на какой-нибудь Windows 98 и были грабли с shared dll section. Но это совсем другая
линейка ОС, не имеющая отношения к NT. И непонятно, какое отношение имеют приоритет фоновых
процессов и виртуализация к теме разделяемой памяти.
C>Как эта штука сейчас работает сложно сказать. Я лично давно эту тему не разбирал, возможно есть какой-то хак для поддержки устаревших приложений, майкрософт даже прямо в код ядра бывает такие хаки вставляет даже для популярных игр (идентификиция процесса, и ему особый режим работы с памятью. пруф найду если надо, был)
Поделитесь ссылкой ?
Лично мне было бы очень интересно.
Re[7]: Использование одной dll в разных процессах.
O>Может быть, на какой-нибудь Windows 98 и были грабли с shared dll section. Но это совсем другая O>линейка ОС, не имеющая отношения к NT. И непонятно, какое отношение имеют приоритет фоновых O>процессов и виртуализация к теме разделяемой памяти.
Сейчас может что-то и поменялось. Я такой штукой баловался еще под Паскалем в седые времена, сделал даже
"плагинный" движок, где через разделенную dll передавались в плагин указатели на процедуры главного процесса.
C>>Как эта штука сейчас работает сложно сказать. Я лично давно эту тему не разбирал, возможно есть какой-то хак для поддержки устаревших приложений, майкрософт даже прямо в код ядра бывает такие хаки вставляет даже для популярных игр (идентификиция процесса, и ему особый режим работы с памятью. пруф найду если надо, был)
O>Поделитесь ссылкой ? O>Лично мне было бы очень интересно.
Ну, вообще, "режим совместимости" в Win7 и запуск 32-битного ПО под x64 виндой это тоже хак, но слишком явный и скучный Я говорил о другом.
Здесь перевод преинтереснейшей статьи:
C>Там в тестах параллельный запуск под второй учетной записью.
И что, требуется, чтобы запуски под двумя учетными записями обязательно взаимодействовали друг с другом ? Это ведь обычно от программ и не требуется. А если они не взаимодействуют, то все пройдет нормально.
Само собой не пройдешь сертификацию Windows Logo (это типа значек такой "Compatible with Windows ZZ"), сразу в разделе "Restart Manager API" — такой хак это фейлы по всем тестам без вариантов.
