Тупик в сторонней dll

Я использую (и ссылаюсь на) две сторонние библиотеки DLL (a.dll и b.dll) в двух своих приложениях C #. Я получаю повторяющуюся проблему, когда оба приложения зависают при вызове функции из сторонней библиотеки.

Я попытался сделать копию a.dll и b.dll (a2.dll и b2.dll) и использовать ее во втором приложении, но оказалось, что a.dll ссылается на b.dll, anb на b.dll ссылки a.dll, и он не загружается должным образом.

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

Итак, мой вопрос: как я могу решить эту проблему?

Могу ли я сказать ОС (Windows XP), что я не хочу, чтобы DLL использовалась совместно?

Спасибо, Джо


c# deadlock dll
person Joe H    schedule 10.07.2009    source источник
comment
Это разные приложения? В этом случае у вас не должно возникнуть проблем с однопоточным доступом, поскольку каждый процесс будет обрабатывать это правильно. Не могли бы вы пояснить, почему вы считаете, что существует тупик.   -  person Michael Donohue    schedule 10.07.2009

Ответы (4)


arrow_upward
4
arrow_downward

Вы можете ограничить доступ только к одной программе за раз, используя именованный мьютекс. Именованные мьютексы могут применяться ко всей операционной системе, поэтому их можно использовать для предотвращения доступа нескольких процессов.

Дополнительные сведения см. В классе Mutex.

person Reed Copsey    schedule 10.07.2009
comment
Должно ли это быть где-то в сторонней DLL или в моем коде? - person Joe H; 10.07.2009
comment
Вы можете поместить это в свой код - это в основном работает как синхронизация вашего потока, за исключением того, что вы можете заблокировать таким образом всю систему ресурсов. - person Reed Copsey; 10.07.2009
comment
Является ли Mutex таким же быстрым, как lock (lockObject)? - person Joe H; 11.07.2009
comment
Нет. Получение именованного мьютекса - гораздо более медленная операция. Однако медленный все же лучше, чем тупик :) - person Reed Copsey; 11.07.2009
comment
У меня есть различные приложения, вызывающие эту dll примерно 5000 раз в секунду при пиковых нагрузках ... поэтому меня беспокоит проблема скорости. Разве нет способа запретить ОС делиться библиотекой? - person Joe H; 11.07.2009
comment
Не совсем. Библиотека действительно должна делать что-то довольно ужасное, чтобы вызывать проблемы при использовании несколькими процессами .... Это не стандартная проблема - в вашем случае обычные средства ОС для обработки изоляции (через процессы) не работают для некоторых причина. - person Reed Copsey; 11.07.2009

arrow_upward
1
arrow_downward

1) В одну сторону

  • Создайте серверное приложение, которое экспортирует / реализует сторонний API и делает API доступным для других / удаленных процессов (например, с помощью удаленного взаимодействия dot net или веб-службы для предоставления доступа к API по сети).
  • В серверном приложении реализуйте его API, делегируя сторонним библиотекам DLL.
  • Запустите только один экземпляр серверного приложения: поэтому используется только один экземпляр сторонних DLL.
  • Ваши существующие приложения должны использовать API, экспортированный вашей службой, вместо использования локальных экземпляров сторонних библиотек DLL.
  • В вашем сервисе внедрите блокировки (что вы можете сделать, потому что теперь это делается в рамках одного процесса).

2) Другой способ: используйте своего рода блокировку, которая видна более чем в одном процессе (например, класс Mutex).

3) Спросите поставщиков сторонних DLL: вы должны иметь возможность запускать только один экземпляр этой DLL за раз? Если вам разрешено запускать более одного экземпляра, что вы должны делать, чтобы избежать взаимоблокировок между процессами?

person ChrisW    schedule 10.07.2009
comment
1) Похоже, много работы :-( 2) Может быть ... 3) Это полузаброшенное ПО с открытым исходным кодом. У них не было обновлений с 2005 года. - person Joe H; 11.07.2009
comment
1) Не сулит ничего хорошего в том, что вы сказали позже, о звонке 5000 раз в секунду. - person ChrisW; 11.07.2009

arrow_upward
1
arrow_downward

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

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

В зависимости от фактической причины это может быть вариант для вас.

person Daniel Rikowski    schedule 10.07.2009

arrow_upward
0
arrow_downward

А как насчет создания другого потока, который отвечает за доступ к этой dll ... Таким образом, все приложение не зависает

person ist_lion    schedule 10.07.2009
comment
Я уже это делаю. Однако у меня остается критический поток в каждом приложении, и оба приложения - хотя и не полностью заморожены - бесполезны. - person Joe H; 10.07.2009