Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Основная";
Текущий архив: 2004.06.20;
Скачать: [xml.tar.bz2];

Вниз

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

 
Прямой   (2004-06-07 11:43) [0]

unit Thread;

interface

uses
Windows, Classes, SYSUTILS, Math, Db,  ADODB, syncobjs;
type TCall = Record
      Strt1: String;
      MSCID1: String;
      Location1: String;
....
end;
type
 TMy = class(TThread)
 private
....
 protected
....
 public
...
end;
Вопрс как сделать класс TCall потоково защищенным?
Думаю что это может быть причиной отваливания потоков.


 
Тимохов ©   (2004-06-07 11:46) [1]


> Вопрс как сделать класс TCall потоково защищенным?

для начала надо создать класс tcall, а уж потом делать его потокозащищенным.


 
Тимохов ©   (2004-06-07 11:50) [2]

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


 
Прямой   (2004-06-07 11:52) [3]

Мне надо использовать тип Record внутри потока. Может ли так как я написал причиной аварийного завершения потоков. Если да, то как правильно сделать чтобы было тип-топ?


 
Тимохов ©   (2004-06-07 11:53) [4]


> Прямой   (07.06.04 11:52) [3]

поймите же - вы ничего не написали.


 
Прямой   (2004-06-07 12:04) [5]

Я имею ввиду то, что создается несколько экземпляров одной функции потока(разница лишь в передаваемых параметрах этой функции). А тип Record(он очень большой) используется как способ передать много разных параметров между процедурами внутри потока(процедур там около 30). Это что-бы не передавать кучу параметров, а передавать только тип запись. Ну естественно все эти присваивания и считывания(в том числе символов из некоторых стрингов). Может ли это привести к разрушению потоков(они ведь лишь экземпляр потока,а TCALL я так понимаю нет)?


 
Тимохов ©   (2004-06-07 12:12) [6]


> Прямой   (07.06.04 12:04) [5]

не обижайтес (сам не всегда понятно выражаюсь), но вас понять не просто.

поэтому два скажу две вещи:
1. Приведите код (сокращенный), где вы используете tcall
2. Общее соображение такое: если есть некая область памяти (запись, переменная - не важно), которая используется (запись/чтение) из разных потоков, то должны применяться средства синхронизации, например - критические секции: tcriticalsection.
пример

var
 record: tcall;
 LockRecord: TCriticalSection;

procedure tmythread.Execute();
begin
  while not Terminated do
  begin
     ...
     LockRecord.Acquire; { lock out other threads }
     try
        здесь изменяешь record
     finally
        LockRecord.Release;
     end;
     ...
  end;
end;

initialization
  LockRecord := TCriticalSectin.Create();
finalization
  FreeAndNil(LockRecord);
end;

и так должно быть во всех потоках, где есть обращение к record


 
evvcom ©   (2004-06-07 12:23) [7]


> Может ли это привести к разрушению потоков

К разрушению потока именно это не приведет, а вот к непредсказуемому изменению данных записи TCall - непременно!
Простой пример. Взять одну переменную и из двух потоков в длинных циклах (например, миллиард итераций) увеличивать его на единицу без какой-либо синхронизации. В конце вместо ожидаемых 2 млрд. результат окажется чем угодно только не 2 млрд.


 
Семен Сорокин ©   (2004-06-07 12:25) [8]

2Прямой

ИМХО лучше TCall сделать классом, а элементы через property, тогда в методах чтения/записи работать через CS, и не надо будет дублировать вышеприведенный код.


 
Прямой   (2004-06-07 12:49) [9]

А еще в ту-же тему
unit Thread;

interface

uses
Windows, Classes, SYSUTILS, Math, Db,  ADODB, syncobjs;
type
 TMy = class(TThread)
 private
FConnect: TADOConnection;//конект с БД
FProc: TADOStoredProc;//хранимая процедура
procedure ConnectBD;      //в этой процедуре происходит коннект к БД из данного потока
protected
public
end;
implementation
.....
Вопрос будет ли FConnect, FProc, и процедура ConnectBD потоково защищена?


 
Тимохов ©   (2004-06-07 12:52) [10]


> Прямой   (07.06.04 12:49) [9]

в общем случае нет.


 
evvcom ©   (2004-06-07 12:59) [11]


> будет ли FConnect, FProc

только если TADOConnection и TADOStoredProc - потоко безопасные.


 
Тимохов ©   (2004-06-07 13:03) [12]


> evvcom ©   (07.06.04 12:59) [11]

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


 
Erik1   (2004-06-07 13:19) [13]

Если у тебя всего один экземпляр TMy то ничего синхронизировать ненадо.


 
evvcom ©   (2004-06-07 13:56) [14]


> они вроде имеют (по-умолчанию)

[11] - Это я в дополнение (пояснение) к общему случаю [10]


 
Прямой   (2004-06-07 13:59) [15]

Если у тебя всего один экземпляр TMy то ничего синхронизировать ненадо.

Нет. Экземпляров столько, сколько поставит в настройках юзер.


 
Тимохов ©   (2004-06-07 14:03) [16]


> Прямой   (07.06.04 13:59) [15]

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


 
panov ©   (2004-06-07 14:37) [17]

>Тимохов ©   (07.06.04 14:03) [16]

В случае схемы Прямой   (07.06.04 12:49) [9]использование критической секции в виде
...
procedure Execute
...
begin
 ...
<  EnterCriticalSection >
  <Подключение к БД>
  <Работа с БД>
  <Окончание работы с БД>
<  LeaveCriticalSection >

абсолютно лишена смысла, так как в этом случае с БД сможет работать только один поток одновременно.


 
Digitman ©   (2004-06-07 14:46) [18]


> тип Record(он очень большой) используется как способ передать
> много разных параметров между процедурами внутри потока


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


 
Empleado ©   (2004-06-07 15:19) [19]

>Прямой   (07.06.04 12:04) [5]
>Я имею ввиду то, что создается несколько экземпляров одной функции потока(разница лишь в передаваемых параметрах этой функции). А тип Record(он очень большой) используется как способ передать много разных параметров между процедурами внутри потока(процедур там около 30). Это что-бы не передавать кучу параметров, а передавать только тип запись. Ну естественно все эти присваивания и считывания(в том числе символов из некоторых стрингов). Может ли это привести к разрушению потоков(они ведь лишь экземпляр потока,а TCALL я так понимаю нет)?

threadvar - ?

fr help: Thread-local (or thread) variables are used in multithreaded applications. A thread-local variable is like a global variable, except that each thread of execution gets its own private copy of the variable, which cannot be accessed from other threads. Thread-local variables are declared with threadvar instead of var.



Страницы: 1 вся ветка

Форум: "Основная";
Текущий архив: 2004.06.20;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.5 MB
Время: 0.03 c
14-1086246365
AlexG
2004-06-03 11:06
2004.06.20
Как заставить программу работать на другом компьютере?


1-1086696134
Ale
2004-06-08 16:02
2004.06.20
Cursor (mouse)


1-1086703741
BlackLord2003
2004-06-08 18:09
2004.06.20
ClipText


1-1086539629
тот же
2004-06-06 20:33
2004.06.20
Дата и INI файл


6-1083257567
Lena19
2004-04-29 20:52
2004.06.20
шаг назад





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский