Текущий архив: 2004.10.31;
Скачать: CL | DM;
Вниз
Класс TTHread Найти похожие ветки
← →
Fktrc © (2004-10-14 06:13) [0]Есть класс потока.
TItemThread = class(TThread)
Таких потоков куча и каждый привязан к элементу ListView
Правильно ли я понимаю, что обращаться к public полям класса TItemThread из главного потока приложения можно без синхронизации, если в потоке TItemThread к этим полям обращений нет?
← →
TUser © (2004-10-14 07:00) [1]А действительно надо к каждому итему свой поток вешать. Их ведь много получается.
← →
Fktrc © (2004-10-14 07:18) [2]Ну пусть даже не надо, но это уже вопрос архитектуры приложения.
А меня интересует следующий узкоспециальный вопрос - можно ли обращаться к public-полям объекта класса TThread из главного потока без синхронизации с вторичным при условии, что вторичный к этим полям не обращается?
← →
TUser © (2004-10-14 07:22) [3]Можно. Синхронизировать надо обращение к VCL из не-основного потока, а к полям класса ты можешь обратиться, как к полям класса.
← →
Sun bittern © (2004-10-14 07:22) [4]TUser © (14.10.04 07:00) [1]
Это смотря сколько много. Полмнится когда то ветка была про нейросеть из не одной тысячи потоков :)
А по сабжу, если написанное действительно так, то можно и без синхронизации.
← →
TUser © (2004-10-14 07:31) [5]Из 2200, кажется. Я бы и 10-15 лишних потоков не делал. Если они делают что-то простое, то нетрудно это совместить в один поток. А если сложное - то один фиг надо искать кластер. Кстати, все сложные программы (такого уровня, как Word, Delphi ect) обходятся несколькими потоками (иногда несколькими процессами с одним или несколькими потоками в каждом).
← →
Fktrc © (2004-10-14 08:36) [6]Спасибо
← →
panov © (2004-10-14 10:18) [7]>Fktrc ©
В случае, если обращение к полям происходит только в одном потоке(неважно, основной это поток или дочерний), в синхронизации нет нужды.
>TUser © (14.10.04 07:22) [3]
Можно. Синхронизировать надо обращение к VCL из не-основного потока, а к полям класса ты можешь обратиться, как к полям класса.
Синхронизировать надо доступ к любым объектам, если обращение к ним происходит из разных потоков, неважно VCL это или не VCL, в основном или дочернем потоке.
← →
panov © (2004-10-14 10:30) [8]PS.
Пример:
TTest=class(TThread)
protected
procedure Execute;override;
public
FValue: Integer;
end;
ptocedure TTest.Execute;
var
Counter: Integer;
begin
...
FValue := Counter;
...
end;
Если Test - экземпляр класса TTest, и обращение к FValue производится таким образом MyValue := Test.FValue, то такой код необходимо защищищать например, критическими секциями:
TTest=class(TThread)
private
FCS: RTL_CRITICAL_SECTION;
FValue: Integer;
finction GetValue: Integer;
procedure SetValue(Value: Integer);
procedure Lock;
procedure Unlock;
protected
procedure Execute;override;
public
constructor Create;
destructor Destroy; override;
property Value: Integr read GetValue write SetValue;
end;
constructor TTest.Create;
begin
inherited Create(True);
InitializeCriticalSection(FCS);
Resume;
end;
destructor TTest.Destroy;
begin
DeleteCriticalSection(FCS);
end;
procedure TTest.Lock;
begin
EnterCriticalSection(FCS);
end;
procedure TTest.Unlock;
begin
LeaveCriticalSection(FCS);
end;
function TTest.GetValue: Integer;
begin
Lock;
try
Result := FValue;
finally
Unlock;
end;
end;
procedure TTest.SetValue(Value: Integer);
begin
Lock;
try
FValue := Value;
finally
Unlock;
end;
end;
ptocedure TTest.Execute;
var
Counter: Integer;
begin
...
FValue := Counter;
...
end;
← →
TUser © (2004-10-14 10:55) [9]
> Синхронизировать надо доступ к любым объектам
Я правильно понял - даже если я напишу свой (не VCL) класс, и использую там везде, где можно CriticalSection, то доступ к объектам этого класса тоже надо синхронизировать? Тогда непонятно - почему так, вроде бы таким образом гарантируется потоко-безопасность?.
Аналогично - к TThreadList"у вроде бы можно обратиться без синхронизации (именно потому, что он защищен критическими секциями, и два потока не могут его одновременно заюзать), так?
← →
panov © (2004-10-14 10:57) [10]да, небезопасный код нужно защищать везде при использовании в разных потоках.
← →
TUser © (2004-10-14 12:08) [11]А в чем тогда смысл критических секций? Они разве не делают код безопасным?
← →
KSergey © (2004-10-14 12:44) [12]> [8] panov © (14.10.04 10:30)
Защита при доступе к Integer?? Или просто для примера?
← →
panov © (2004-10-14 13:06) [13]>KSergey © (14.10.04 12:44) [12]
Да. Integer тоже надо защищать.
← →
panov © (2004-10-14 13:09) [14]>KSergey © (14.10.04 12:44) [12]
Сразу поясню свою мысль:
заранее неизветсно, на каких процессорах будет испольняться код, и как будет определен тип integer, поэтому не факт, что даже присвоение (RC=18, например), будет являться атомарной операцией.
← →
panov © (2004-10-14 13:12) [15]Тем более, на компьютерах с несколькими процессорами.
Страницы: 1 вся ветка
Текущий архив: 2004.10.31;
Скачать: CL | DM;
Память: 0.5 MB
Время: 0.047 c
