Потоки внутри DLL

[Человек_Борща]

Доброго времени!

Есть некая DLL которая имеет примерно такую структуру:

var
 CritSect:TCriticalSection;
 aObjects:array of TWorkObject;


TSomeExternalClass.GetObject(...):IWorkObject;
var
 i, ...
begin
 CritSect.Enter;
 try
   ...
   Result := aObject[i];
...
 finally
    CritSect.Leave;
 end;
end;

TWorkObject.DoMonkeysJob;
begin
 while true do
....
end;

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

GetObject внешнего класса(его дергает приложение вызывающее DLL), возвращает из массива объект, крит. секция блокирует доступ к GetObject пока эта функция занята в другом потоке внешнего приложения, т.е. нельзя чтобы чего-то два штуки получили один TWorkObject.

Но дилема в другом, приложение подвисает целиком на 700 мс - 2 сек.(в его контекст загружена DLL) что создает очень большие проблемы, т.к. нагрузка большая и работа тоже не маленькая, которую кстати и выполняет эта библиотека(пара тысяч единиц данных в секунду).
Подвисает при условии что, в массиве минимум 6 объектов свободны, и проблем особо с получением объекта нет.

Итого наблюдаю задержку от 700 мс до 2-5 сек. Иногда вообще ступор и все висит минут 5(это уже ПИ***Ц).

И вот вопрос:
Решится ли проблема зависания основного потока с DLL если каждый TWorkObject будет отдельным потоком внутри DLL для выполнения тяжелых под-задач?

[Stilet]

Решится ли проблема зависания основного потока с DLL если каждый TWorkObject будет отдельным потоком внутри DLL для выполнения тяжелых под-задач?

По идее должна решиться. Вот только критическую секцию нужно как-то уменьшить.
А вообще я бы создал конкретно для этой цели отдельный экзешник. Вопрос конечно в том что передавать и как, если это объект то пичаль, а если простые данные то ИМХО так будет проще.

[indexx]

По идее нет. Потоку, работающему с dll так и так придётся ждать выполнение работы внутри библиотеки. Соответственно поток будет висеть. Выход - доп поток в основном коде, или как вариант, попытка синхронизации dll с программой.

[Stilet]

Соответственно поток будет висеть.

Я ошибаюсь или автору нужно разгрузить основной поток?
Тогда не понимаю твоей мысли: в ДЛЛ организовывается поток, который не мешает другим что-то делать параллельно.

[Пепел Феникса]

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

потоков тут вообще не наблюдаю.

[Человек_Борща]

По идее должна решиться. Вот только критическую секцию нужно как-то уменьшить.

Он и так маленький. Внутри стоит for по массиву с кучей проверок самого массива(больше их ставить просто негде).

А вообще я бы создал конкретно для этой цели отдельный экзешник. Вопрос конечно в том что передавать и как, если это объект то пичаль, а если простые данные то ИМХО так будет проще.

Отдельный exe врядли.
Возвращается интерфейс объекта для работы с ним.

Тогда не понимаю твоей мысли: в ДЛЛ организовывается поток, который не мешает другим что-то делать параллельно.

исхожу из того, что в библиотеке сейчас нет доп. потоков. Грузится она в основной exe, а работают с ней в других доп. потоках основной программы. Получается, когда 1 из этих потоков делает тяжелую задачу, осн. приложение тупо зависает.

Мне нужно это убрать вместе с замиранием доп-потоков

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

Если быбыло видно, я бы тему не создавал Таких процедур там минимум 10.

потоков тут вообще не наблюдаю.

Они у основной программы, цепляют функции DLL.

[Пепел Феникса]

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

в общем, нужно ли программе результат этих функций.

PS: для отладки могли и выкинуть лишний тяжелый код на время, чтоб определить где виснет.

[Человек_Борща]

в общем, нужно ли программе результат этих функций.

Нет. там методы. Их работа вероятно вешает все ПО через эту библиотеку. Если это вообще возможно.

Из отладки у меня только несколько гб логов

Если объекты превратить в потоки с этими объектами, решит ли это проблему?

[Пепел Феникса]

а что методам запрещают возвращать результат?

программе нужен результат выполнения? или она их дергает с темой "а пусть само работает"
если второе то проблем нет.
в первом случае ничего не меняется, ибо программа будет ждать результат все равно.