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

Вниз

Класс 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;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.48 MB
Время: 0.034 c
3-1096876376
neat
2004-10-04 11:52
2004.10.31
DBGrid: увеличение высоты строки


4-1096284308
Rifo
2004-09-27 15:25
2004.10.31
Отключение монитора.


1-1098266599
Pitonec
2004-10-20 14:03
2004.10.31
6 и 7 Delphi


1-1098064879
smile_t
2004-10-18 06:01
2004.10.31
масштабирование


14-1097224980
Darts
2004-10-08 12:43
2004.10.31
Библиотека для получения (отправки почты)





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
Английский Французский Немецкий Итальянский Португальский Русский Испанский