Есть несколько потоков. Каждый загружает себе одну и туже библиотеку, вызывает метод (установка соединения с базой внутри библиотеки) и дальше каждый занимается своими делами используя процедуры работы с БД загруженные из библиотеки.
Дак вот вопрос, если у меня 4 потока, то будет ли для каждого потока создано отдельное подключение к БД?
И если я буду выполнять одновременно из разных потоков запрос на запись/чтение из базы то как это будет работать.

Здравствуйте, Аноним, Вы писали:

А>Есть несколько потоков. Каждый загружает себе одну и туже библиотеку, вызывает метод (установка соединения с базой внутри библиотеки) и дальше каждый занимается своими делами используя процедуры работы с БД загруженные из библиотеки.
А>Дак вот вопрос, если у меня 4 потока, то будет ли для каждого потока создано отдельное подключение к БД?
если ты 4 раза вызвал метод подключения к базе, то естественно будет 4 подключения.

А>И если я буду выполнять одновременно из разных потоков запрос на запись/чтение из базы то как это будет работать.
так как ты написал приложение, так и будет работать

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

J>если ты 4 раза вызвал метод подключения к базе, то естественно будет 4 подключения.

В том-то и проблема что не работает. Есть два потока, они запускаются одновременно и работают с базой. Каждый загружает библиотеку, загружает процедуры. Но при выполнении в одном из потоков (в том что оказался позже) вылазит сообщение что не может выполнить операцию на закрытом датасэте.
Если запустить один поток и после того как он отработает запустить второй то все работает, при том не зависимо от того какой поток будет первым.

Здравствуйте, Аноним, Вы писали:

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

J>>если ты 4 раза вызвал метод подключения к базе, то естественно будет 4 подключения.

А>В том-то и проблема что не работает. Есть два потока, они запускаются одновременно и работают с базой. Каждый загружает библиотеку, загружает процедуры. Но при выполнении в одном из потоков (в том что оказался позже) вылазит сообщение что не может выполнить операцию на закрытом датасэте.
А>Если запустить один поток и после того как он отработает запустить второй то все работает, при том не зависимо от того какой поток будет первым.

Глобальные переменные используешь??

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

J>Глобальные переменные используешь??

Где? В библиотеке использую. В самом приложении нет.

Здравствуйте, <Аноним>, Вы писали:

J>>Глобальные переменные используешь??

А>Где? В библиотеке использую. В самом приложении нет.

Неважно где. Копия библиотеки (а значит и ее глобальных переменных) у тебя одна на процесс (не на поток). Только если ты не объявил эти переменные как thread-unique (спецификатор __declspec(thread) для Visual C++ или threadvar для дельфи). Если от этих переменных каким-то образом зависит работа с БД, то, вероятней всего, проблема именно в них.

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

E>Здравствуйте, <Аноним>, Вы писали:

J>>>Глобальные переменные используешь??

А>>Где? В библиотеке использую. В самом приложении нет.

E>Неважно где. Копия библиотеки (а значит и ее глобальных переменных) у тебя одна на процесс (не на поток). Только если ты не объявил эти переменные как thread-unique (спецификатор __declspec(thread) для Visual C++ или threadvar для дельфи). Если от этих переменных каким-то образом зависит работа с БД, то, вероятней всего, проблема именно в них.

Верняк Полностью с вами согласен.
Постоянная ошибка при начале работы с DLLками. LoadLibrary — это не значит что загрузится новая DLL со своими переменными. Это значит что если она еще не загружена то ее загрузят и увеличат подсчет ссылок загрузки. В данном случае, потоки будут конфликтовать друг с другом на уровне глобальных переменных (и кто вас учил так писать...)

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

E>Неважно где. Копия библиотеки (а значит и ее глобальных переменных) у тебя одна на процесс (не на поток). Только если ты не объявил эти переменные как thread-unique (спецификатор __declspec(thread) для Visual C++ или threadvar для дельфи). Если от этих переменных каким-то образом зависит работа с БД, то, вероятней всего, проблема именно в них.

Т.е. если не использовать threadvar то я буду работать с одной и той же процедурой, если я несколько раз (в каждом потоке по разу) вызову GetProcAddress()?
Простите за глупый вопрос, но как в качестве поля класса объявить threadvar?
Сейчас так:

TSomeThread = class(TThread)
private
  FMethod1: TMethod1;
...

Здравствуйте, <Аноним>, Вы писали:

А>Т.е. если не использовать threadvar то я буду работать с одной и той же процедурой, если я несколько раз (в каждом потоке по разу) вызову GetProcAddress()?

В смысле с одной и той же процедурой? Код процедуры естественно один на процесс, но стек будет свой для каждого потока

А>Простите за глупый вопрос, но как в качестве поля класса объявить threadvar?

Нельзя так.

А>Сейчас так:

А>

А>TSomeThread = class(TThread)
А>private
А>  FMethod1: TMethod1;
А>...
А>

Если у тебя на каждый поток есть объект вот такого вот класса, то естественно никакой проблемы нет

Здравствуйте, Аноним, Вы писали:

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

E>>Неважно где. Копия библиотеки (а значит и ее глобальных переменных) у тебя одна на процесс (не на поток). Только если ты не объявил эти переменные как thread-unique (спецификатор __declspec(thread) для Visual C++ или threadvar для дельфи). Если от этих переменных каким-то образом зависит работа с БД, то, вероятней всего, проблема именно в них.

А>Т.е. если не использовать threadvar то я буду работать с одной и той же процедурой, если я несколько раз (в каждом потоке по разу) вызову GetProcAddress()?
А>Простите за глупый вопрос, но как в качестве поля класса объявить threadvar?

Да не при использовании библиотеки, а при ее написании. Тоесть заберите в DLL к черту все глобальные переменные или замените их на theadvar (лучше всетаки забрать). Я надеюсь вам не надо обьяснять что такое глобальные переменные, а то опять на поле класса покажете?

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

E>Если у тебя на каждый поток есть объект вот такого вот класса, то естественно никакой проблемы нет

Да, именно так.
Тут в соседней ветке подсказывают что в библиотеке нужно глобальные переменный с var на threadvar поменять, это так?

Здравствуйте, Аноним, Вы писали:

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

E>>Если у тебя на каждый поток есть объект вот такого вот класса, то естественно никакой проблемы нет

А>Да, именно так.
А>Тут в соседней ветке подсказывают что в библиотеке нужно глобальные переменный с var на threadvar поменять, это так?

Алелуйя, интересно о чем мы тут толкуем уже столько времени
Только просто тупой заменой на theardvar не обойдешся. Тут нужно будет логику подправлять. Если вы в этих переменных держите классы, то кто их будет освобождать при завершении потока? Память у вас уйдет быстренько...

Самое правильное это: переписать DLL так чтобы она не содержала глобальных переменных или имела только самые необходимые или чтобы они были threadsafe.