Вопрос на понимание потоков

← →
yurikon (2012-04-13 11:38) [0]

Добрый день всем!

Прочитал всю справку делфи по потокам. Трабл с одновременной работой с данными мне понятен. Не понятно вот что. Могут ли два потока "одновременно" вызвать процедуру из третьего юнита и исполнится ли эта процедура параллельно в двух потоках или будет некая очередность?

С уважением.

← →
Inovet © (2012-04-13 11:42) [1]

Могут.

← →
Cobalt © (2012-04-13 12:37) [2]

Вызвать могут.
исполняться она будет параллельно-очередно, т.е. в обоих потоках, в своих квантах времени (нет никакой гарантии, что оба вызова (если были произведены одновременно) "закончатся" одновременно)

← →
yurikon (2012-04-13 15:29) [3]

Получается, что каждый поток создает для себя копию таблиц процедур, которые он использует?

← →
Сергей М. © (2012-04-13 15:30) [4]

не получается.
в одном экземрпляре они)

← →
Cobalt © (2012-04-13 16:12) [5]

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

← →
Германн © (2012-04-14 02:48) [6]

> yurikon (13.04.12 15:29) [3]
>
> Получается, что каждый поток создает для себя копию таблиц
> процедур, которые он использует?

А на хрена ему это нужно? Секция кода используется процессом и его потоками только для чтения.

← →
yurikon (2012-04-27 16:13) [7]

Подниму топик с вашего позволения )).

Есть два потока, они вызывают одну и ту же процедуру, которая добавляет строку в TStringList (простой вариант логирования). Требуется ли в таком случае использовать критическую секцию?

С уважением.

← →
RWolf © (2012-04-27 16:24) [8]

если добавляют в один и тот же лист — то да.

← →
Медвежонок Пятачок © (2012-04-27 16:30) [9]

Есть два потока, они вызывают одну и ту же процедуру, которая добавляет строку в TStringList (простой вариант логирования).

Это не простой, а неправильный вариант логирования.
Из вторичных потоков нельзя трогать гуи.

← →
yurikon (2012-04-27 16:57) [10]

Просто с крит. секцией прога виснет, хотя делаю как в хелпе. Ок. Разберусь.

2 Медвежонок Пятачок:

Поясните, плиз, как в таком случае из потока передать инфо в основную прогу?

С уважением.

← →
Медвежонок Пятачок © (2012-04-27 16:58) [11]

сенд/пост мессадж, архангельский синхронайз,.....
мильон способов.

← →
yurikon (2012-04-27 17:00) [12]

> архангельский синхронайз

В смысле "архангельский синхронайз" ?

Synhronize(...) - этот или есть еще другой?

← →
KSergey © (2012-04-27 17:05) [13]

> Медвежонок Пятачок © (27.04.12 16:30) [9]
> Из вторичных потоков нельзя трогать гуи.

TStringList - это не GUI.

← →
KSergey © (2012-04-27 17:07) [14]

> yurikon (27.04.12 16:13) [7]
> Есть два потока, они вызывают одну и ту же процедуру, которая
> добавляет строку в TStringList (простой вариант логирования).
> Требуется ли в таком случае использовать критическую секцию?

Вы ведь писали:

> yurikon (13.04.12 11:38)
> Прочитал всю справку делфи по потокам. Трабл с одновременной работой с данными мне понятен.

Если речь про один и то же экземпляр TStringList, тогда то, о чем вы спрашиваете - и есть "одновременная работа с данными" из разных потоков

← →
KSergey © (2012-04-27 17:10) [15]

> yurikon (27.04.12 17:00) [12]
> Synhronize(...) - этот или есть еще другой?

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

Чтобы потоки работали параллельно и одновременно (сейчас не будет углубляться в кванты времени) - надо минимизировать модификацию ими одних и тех же данных, в лучше всего - и вовсе исключить. Иначе на синхронизации весь кайф будет потерян.

← →
yurikon (2012-04-27 17:24) [16]

> Но надо понимать, что если собственно логирование занимает
> заметное (или основное) время работы потоков - то фактически
> этим параллельность вы убиваете.

Спасибо за пояснение. Нет, логирование не занимает много ресурсов потока.

С этим понял. Еще вопрос.
Я использую ADOConnection.Execute(..);

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

← →
Медвежонок Пятачок © (2012-04-27 17:30) [17]

TStringList - это не GUI.

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

← →
yurikon (2012-04-27 17:40) [18]

> конечно не гуи. только через пять минут окажется что это
> листбокс.

Чувствуется почерк мастера ;-))))). Memo, а так почти в точку.

Так что на счет ADO ?

← →
Медвежонок Пятачок © (2012-04-27 17:44) [19]

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

← →
yurikon (2012-04-27 18:21) [20]

Докладываю, сделал тест. Два потока, используя одно соединение непрерывно изменяют таблицу. Все работает.

Но все равно для потока сделал свое соединение...

> Два потока, используя одно соединение непрерывно изменяют таблицу. Все работает.
одно соединение скорее всего само организует очередь команд независимо от "твоих" потоков. да и мало 2х для тестов... давно делал тест для проверки аксесс (по умолчанию/настроено 5 потоков/соединений держит), так 5 машин (именно с разных машин, вс на одной эффекта не давало) у меня непрерывно вело запись в базу, и одна (6-е, лишнее соединение) их удаляла... и оставлял я эту "систему" на три дня выходных... после смотрел по логам ошибки. и было их где то 1 на 1000 итераций... да и то не сразу, а как база некий критический объем набрала (не справлялось 6-е с удалением, по чуть чуть но росла база).
и это с ограниченным "локальным" движком, использовав в сети... а вот как можно нагрузить MSSQL например, так чтобы он начал "глюкать" даже не представляю...

хочешь реальную много поточность в ADO, делай либо отдельными коннектами в потоках, либо средствами самого ADO (имхо предпочтительнее).

> sniknik © (28.04.12 07:44) [21]
> .. да и то не сразу, а как база некий критический объем
> набрала (не справлялось 6-е с удалением, по чуть чуть но росла база).

Это не про то эксперимент, это про производительность БД.

> Это не про то эксперимент
именно про то
при увеличении размера операции стали дольше, и начались проблемы с локированием потоков, пересечения операций в одно и тоже время из разных.
а так то, пусть будет хоть миллион потоков, если они выполняются так, что общие ресурсы "трогают" каждый строго в свое время, без пересечений, то никакие синхронизации не нужны.
2-то уж точно не показатель.

да что там рассуждать "показатель - не показатель" ?
в реестре черным по белому написано

HKEY_CLASSES_ROOT\ADODB.Connection\CLSID = {00000514-0000-0010-8000-00AA006D2EA4}

HKEY_CLASSES_ROOT\CLSID\{00000514-0000-0010-8000-00AA006D2EA4}\InprocServer32
ThreadingModel = Apartment

А раз Apartment, то ССЗБ, пытающийся использовать этот COM-объект одновременно более чем в одном потоке, делает это искл-но на свой страх и риск.

← →
yurikon (2012-04-28 15:52) [25]

Спасибо за обсуждение!

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

При закрытии программы делаю Terminate, затем Free для потока. Иногда вылетает ошибка доступа к данным. Возможно по этой причине...

> Как понять что метод Execute потока завершил работу

mythread.WaitFor;

← →
yurikon (2012-04-28 16:11) [27]

Благодарю! Теперь все корректно завершается.

> Сергей М. © (28.04.12 09:57) [24]

О! Спасибо
А то я знал (просто как мантру), что для каждого потока - обязательно свой ADOConnection, иначе беда, но у меня не было аргументов для атеистов.

Вопрос на понимание потоков Найти похожие ветки