Создание обекта в потоке (Thread)

← →
Tonich © (2006-07-04 01:26) [0]

Доброй ночи..
Такой вопрос, а в чем собственно различие между созданием объекта в Create и Execute класса TThread. При создании объекта в том или ином месте на выходе имею различные результаты.

Спасибо...

← →
Пусик © (2006-07-04 01:32) [1]

Конструктор выполняется в контексте вызывающего потока. объект, соответственно, создается в нем же. При создании в поточной функции объект "живет" в этом потоке.

← →
Tonich © (2006-07-04 01:38) [2]

мм бонятно пасибо ))

← →
Джо © (2006-07-04 01:38) [3]

> При создании объекта в том или ином месте на выходе имею
> различные результаты.

Какие результаты, в чем они различны и на выходе из чего?

← →
Tonich © (2006-07-04 01:46) [4]

> Какие результаты
- результата выполнения отдельного потока

> в чем они различны
- различны они в том что получаются, соврем разные значения определенных величин (которые вычисляются тем объектом который создается) при одинаковых начальных условиях

> на выходе из чего

- ну я не имел ввиду буквально, как на пример на выходе функции получаем результат. Я имел ввиду, по окончанию выполнения потока.

← →
Германн © (2006-07-04 02:14) [5]

> > в чем они различны - различны они в том что получаются,
> соврем разные значения определенных величин (которые вычисляются
> тем объектом который создается) при одинаковых начальных
> условиях

Вот и ищи различия, которые могут получиться в вычислении тех самых определенных величин (которые вычисляются
тем объектом который создается) .
Причём ищи в своём тексте программы. Само создание объекта - всегда одинаково. Если его поля не привязаны к переменным программы.

← →
evvcom © (2006-07-04 08:11) [6]

> - различны они в том что получаются, соврем разные значения
> определенных величин (которые вычисляются тем объектом который
> создается) при одинаковых начальных условиях

Наиболее вероятная причина - отсутствие/нарушение синхронизации доступа к этим "определенным величинам" и/или "начальным условиям".

← →
Tonich © (2006-07-04 11:49) [7]

> Германн © (04.07.06 02:14) [5]

да откуда возьмутся различия в вычислениях величин, если это один и тот же объект с одними и теми же методами и полями..ощибка в начальных условиях тоже исключена так как они берутся из одних и тех же переменных, определенных до создания самого объекта.
А что
> Пусик © (04.07.06 01:32) [1]

не правельный, я почему-то склоняюсь именно к этому

← →
DrPass © (2006-07-04 12:35) [8]

> Конструктор выполняется в контексте вызывающего потока.
> объект, соответственно, создается в нем же. При создании
> в поточной функции объект "живет" в этом потоке.

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

← →
Пусик © (2006-07-04 13:10) [9]

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

Ошибаешься. Могу согласиться с обычными потоками, но не с потоками VCL (TTherad).

← →
Romkin © (2006-07-04 13:12) [10]

Вот только если объект обрабатывает сообщения, то разница где создавать есть, и существенная. Пример - TTimer. Его точно нужно создавать в execute ;)

← →
DrPass © (2006-07-04 13:30) [11]

> Пусик © (04.07.06 13:10) [9]

> Могу согласиться с обычными потоками, но не с потоками VCL
> (TTherad)

Хочешь поспорить? Тогда просто докажи :) Единственное условие - см.

> Romkin © (04.07.06 13:12) [10]

...но это известный факт. Компоненты VCL непотокобезопасные, и обращения к созданным в главном потоке объектам VCL приведут к AV

← →
Игорь Шевченко © (2006-07-04 13:38) [12]

> Компоненты VCL непотокобезопасные, и обращения к созданным
> в главном потоке объектам VCL приведут к AV

Не факт

← →
DrPass © (2006-07-04 13:40) [13]

> Игорь Шевченко © (04.07.06 13:38) [12]
>
> Не факт

обращения к созданным
в главном потоке объектам VCL в определенных случаях приведут к AV

Так понятнее? :-)

← →
Игорь Шевченко © (2006-07-04 13:43) [14]

DrPass © (04.07.06 13:40) [13]

> обращения к созданным
> в главном потоке объектам VCL в определенных случаях приведут
> к AV
>
> Так понятнее? :-)

Безусловно. А главное - точнее :)

← →
Пусик © (2006-07-04 13:44) [15]

> DrPass © (04.07.06 13:30) [11]

> Единственное условие - см.

Уверен?

Использование Mutex в объекте - вот тебе второе условие.

Еще спорить будешь?

Или скажешь, что это второе и одно из двух единственных условий?

Надо будет, можно еще примеры привести.

← →
Пусик © (2006-07-04 13:44) [16]

> DrPass © (04.07.06 13:40) [13]
> > Игорь Шевченко © (04.07.06 13:38) [12] > > Не фактобращения
> к созданным в главном потоке объектам VCL в определенных
> случаях приведут к AVТак понятнее? :-)

И это не факт.

← →
Пусик © (2006-07-04 13:47) [17]

>DrPass ©
Кстати, вот это поясни:

> Поток - это не сущность, в которой что-либо живет, а просто
> состояние процессора.

← →
Пусик © (2006-07-04 13:49) [18]

>DrPass ©

Еще добавлю, что есть принципиальные вопросы, а есть буквоедство.
Есть юмор, а есть ошибки.

Хочешь поговорить о потоках? Давай поговорим.

← →
Игорь Шевченко © (2006-07-04 14:34) [19]

Пусик © (04.07.06 13:10) [9]

> Ошибаешься. Могу согласиться с обычными потоками, но не
> с потоками VCL (TTherad).

Если не секрет, чем объект, созданный внутри TThread отличается от объекта, созданного в основном потоке VCL ?

← →
Игорь Шевченко © (2006-07-04 14:51) [20]

Вот есть небольшой код, вроде там объекты несильно зависят от места их создания:

unit main; interface uses Classes, Forms, StdCtrls, Foo, Controls; type TfMain = class(TForm) Button1: TButton; Button2: TButton; Button3: TButton; Label1: TLabel; Label2: TLabel; procedure FormDestroy(Sender: TObject); procedure Button1Click(Sender: TObject); procedure Button3Click(Sender: TObject); procedure Button2Click(Sender: TObject); public FFoo1: TFoo; FFoo2: TFoo; end; var fMain: TfMain; implementation uses Bar; {$R *.DFM} procedure TfMain.FormDestroy(Sender: TObject); begin FFoo1.Free; FFoo2.Free; end; procedure TfMain.Button1Click(Sender: TObject); begin FFoo1 := TFoo.Create ("Main thread"); end; procedure TfMain.Button3Click(Sender: TObject); begin if Assigned(FFoo1) then Label1.Caption := FFoo1.Prop; if Assigned(FFoo2) then Label2.Caption := FFoo2.Prop; end; procedure TfMain.Button2Click(Sender: TObject); begin TBar.Create (Self); end; end.

unit Foo; interface type TFoo = class private FProp: string; public constructor Create (const AProp: string); property Prop: string read FProp; end; implementation { TFoo } constructor TFoo.Create(const AProp: string); begin FProp := AProp; end; end.

unit Bar; interface uses Classes, main; type TBar = class(TThread) private FOwner: TfMain; protected procedure Execute; override; public constructor Create (Owner: TfMain); end; implementation uses Foo; { TBar } constructor TBar.Create(Owner: TfMain); begin FOwner := Owner; inherited Create (false); end; procedure TBar.Execute; begin FOwner.FFoo2 := TFoo.Create ("TThread"); end; end.

← →
Пусик © (2006-07-04 15:06) [21]

> Если не секрет, чем объект, созданный внутри TThread отличается
> от объекта, созданного в основном потоке VCL ?

Не просто объект, а некоторые из объектов.

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

← →
Пусик © (2006-07-04 15:07) [22]

> Игорь Шевченко © (04.07.06 14:51) [20]
> Вот есть небольшой код, вроде там объекты несильно зависят
> от места их создания:

А разве разговор был про ВСЕ и ЛЮБЫЕ объекты?

← →
Игорь Шевченко © (2006-07-04 15:23) [23]

Пусик © (04.07.06 15:07) [22]

> А разве разговор был про ВСЕ и ЛЮБЫЕ объекты?

В постах [8] и [9] или до них был очерчен круг объектов, о которых ведется разговор ? Или я что-то пропустил ?

Пусик © (04.07.06 15:06) [21]

> Не просто объект, а некоторые из объектов.

Если объекты используют особенности операционной системы, относящиеся к разным потокам, то да, отличия будут. Но сами объекты разве сильно зависят от того, в каком потоке они созданы ?

> в частности - одной из причин (от Romkin) вполне достаточно
> для того, чтобы видеть эти различия.

Конечно, сообщения, о которых упоминал Romkin, приходят к каждому потоку не смешиваясь. Но причем тут объекты ?

← →
Пусик © (2006-07-04 16:13) [24]

> Игорь Шевченко © (04.07.06 15:23) [23]
> Пусик © (04.07.06 15:07) [22] > А разве разговор был про
> ВСЕ и ЛЮБЫЕ объекты?В постах [8] и [9] или до них был очерчен
> круг объектов, о которых ведется разговор ? Или я что-то
> пропустил ?

А это аргумент в чью пользу?

Если ты аргументируешь свою позицию, то в [8] как раз неверное обобщение и этот пост не в твою пользу.

> Если объекты используют особенности операционной системы,
> относящиеся к разным потокам, то да, отличия будут. Но
> сами объекты разве сильно зависят от того, в каком потоке
> они созданы ?

Может быть стоит вспомниить базовые понятия ООП, в частности, инкапсуляцию?
Объект - это не только его поля-свойства, но и его методы.
Соответственно, под объектом нужно понимать и его поведение.
И не имеет значения то, что в объекте инкапсулированы методы, использующие особенности операционной системы. Объект от этогоне перестает быть объектом.

То же касается и

> Конечно, сообщения, о которых упоминал Romkin, приходят
> к каждому потоку не смешиваясь. Но причем тут объекты ?

PS.
Надо почаще освежать в памяти базовые понятия.

← →
DrPass © (2006-07-04 16:16) [25]

> Пусик © (04.07.06 13:47) [17]
> >DrPass ©
> Кстати, вот это поясни:
>
> > Поток - это не сущность, в которой что-либо живет, а
> просто
> > состояние процессора.

Поясняю - не существует такого понятия, как код потока. Код в программе один общий для всех, использует одну и ту же память, и одни и те же данные в этой памяти. Объект - это тоже код+данные. А поток - это именно состояние процессора. Грубо говоря, набор параметров, который описывает исполняемый в настоящий момент участок кода.
P.S. А причем здесь

> Использование Mutex в объекте - вот тебе второе условие

это?

← →
Игорь Шевченко © (2006-07-04 16:19) [26]

Пусик © (04.07.06 16:13) [24]

> Может быть стоит вспомниить базовые понятия ООП, в частности,
> инкапсуляцию?
> Объект - это не только его поля-свойства, но и его методы.
>
> Соответственно, под объектом нужно понимать и его поведение.
>
> И не имеет значения то, что в объекте инкапсулированы методы,
> использующие особенности операционной системы. Объект от
> этогоне перестает быть объектом.

Это все хорошо, но каким образом это относится к сабжу ?

> Надо почаще освежать в памяти базовые понятия.

Да, спасибо. Совет учтен.

← →
Пусик © (2006-07-04 16:43) [27]

> Это все хорошо, но каким образом это относится к сабжу ?

А все таким же. Те же самые и все о том же. Вместо конкретного опровержения опять словоблудие.

Объект есть данные и реализация обработки их.
И использование некоторых объектов в доп. потоке отличается от использования в основном потоке вследствие именно реализации обработки данных и в взаимодействия с другими объектами.

Сколько раз эту фразу повторить?

← →
Пусик © (2006-07-04 16:48) [28]

>DrPass © (04.07.06 16:16) [25]

> А поток - это именно состояние процессора.

Не буду писать от себя, проще процитировать того же Рихтера:

"...В той же главе 4 я упомянул, что процессы инертны Процесс ничего не исполня ет, он просто служит контейнером потоков Потоки всегда создаются в контексте какого-либо процесса, и вся их жизнь проходит только в его границах На практике это означает, что потоки исполняют код и манипулируют данными в адресном про странстве процесса Поэтому, если два и более потоков выполняется в контексте од ного процесса, все они делят одно адресное пространство Потоки могут исполнять один и тот же код и манипулировать одними и теми же данными, а также совместно использовать описатели объектов ядра, поскольку таблица описателей создается нс в отдельных потоках, а в процессах..."

← →
Пусик © (2006-07-04 16:49) [29]

>DrPass © (04.07.06 16:16) [25]
Описание несколько отличается от твоего. Верно?

← →
Пусик © (2006-07-04 16:50) [30]

+ "В главе 4 я говорил, что процесс фактически состоит из двух компонентов объекта ядра "процесс" и адресного пространства так вот, любой поток тожс состоит из двух компонентов.

объекта ядра, через который операционная система управляет потоком Там же хранится статистическая информация о потоке;
стека потока, который содержит параметры всех функций и локальные пере менные, необходимые потоку для выполнения кода (О том, как система управ ляет стеком потока, я расскажу в главе 16) "

← →
DrPass © (2006-07-04 16:53) [31]

> Пусик © (04.07.06 16:43) [27]

> использование некоторых объектов в доп. потоке отличается
> от использования в основном потоке

Хм... и как по-твоему, это какое-то отношение имеет к самим объектам, или все-таки является причиной сознательного коверканья кода программы?
Твое утверждение равноценно утверждению "использование объектов в процедурах на букву А отличается от использования объектов в процедурах на букву В". Да, можно специально написать такой объект, использующий глобальную переменную, которой будет присваиваться разное значение в разных процедурах... но к общим правилам использования объектов это никакого отношения не имеет. Это просто "кривые ручки программиста".
Здесь не суд, поэтому выискивать "юридические лазейки" в определениях и правилах не стоит.

← →
DrPass © (2006-07-04 16:57) [32]

> Пусик © (04.07.06 16:49) [29]
> >DrPass © (04.07.06 16:16) [25]
> Описание несколько отличается от твоего. Верно?

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

← →
Пусик © (2006-07-04 17:08) [33]

> DrPass © (04.07.06 16:53) [31]

Начну с последнего предложения:

> Здесь не суд, поэтому выискивать "юридические лазейки" в
> определениях и правилах не стоит.

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

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

Поведение объекта в разных потоках может отличаться. С этим будешь спорить?
Если нет, тогда продолжу.
Вопрос не о том, что для того, чтобы объект вел себя одинаково, нужно затратить дополнительные усилия при его использовании, а в том, что такие усилия вообще нужны.
И совсем необязательно коверкать код, чтобы получить подобные эффекты.

> Твое утверждение равноценно утверждению "использование объектов
> в процедурах на букву А отличается от использования объектов
> в процедурах на букву В"

Процедуры и потоки - суть разные вещи. Не надо передергивать.

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

Речь не идет о глобальных переменных, и ты это прекрасно понимаешь.
Классы могут быть разного назначения, в том числе и для взаимодействия с пользователем(к примеру), скрывающие в себе и использующие ACtiveX, Com-объекты..
И, естественно, кривые ручки программиста здесь ни при чем, так как разговор не об этом идет.

← →
Пусик © (2006-07-04 17:10) [34]

> DrPass © (04.07.06 16:57) [32]
> > Пусик © (04.07.06 16:49) [29] > >DrPass © (04.07.06
> 16:16) [25]> Описание несколько отличается от твоего. Верно?
> И чем оно противоречит моему? Тем, что Рихтер сказал "потоки
> исполняют код и манипулируют данными"? Это допущение для
> более простого понимания. Не более того. Поток физически
> ничем не манипулирует. Манипулирует процессор, а поток описывает
> его состояние.

Хм. Как я понимаю, все зависит от процессора, а не от операционной системы?

← →
Игорь Шевченко © (2006-07-04 17:13) [35]

Пусик © (04.07.06 16:43) [27]

> Вместо конкретного опровержения опять словоблудие.

Да сдалось ты мне - опровергать тебя. Таблеток от хамства побольше купи, ламер.

← →
DrPass © (2006-07-04 17:15) [36]

> Пусик © (04.07.06 17:08) [33]
> Вопрос не о том, что для того, чтобы объект вел себя одинаково,
> нужно затратить дополнительные усилия при его использовании,
> а в том, что такие усилия вообще нужны.
> И совсем необязательно коверкать код, чтобы получить подобные
> эффекты

Хотите аргументов? Да пожалуйста:
type TMyClass = class end;
И какие мне нужны усилия, чтобы это объект вел себя неодинаково в зависимости от создавшего его потока? Более того, я могу навернуть в него любую функциональность, и он все равно будет вести себя одинаково.
А вот чтобы он вел себя неодинаково... вот тут уже нужно будет действительно прилагать усилия.

> Процедуры и потоки - суть разные вещи. Не надо передергивать

Вещи разные. А вот смысл утверждений в обоих случаях совершенно одинаков.
И еще раз, плиз, см.

> Здесь не суд, поэтому выискивать "юридические лазейки" в
> определениях и правилах не стоит

← →
Пусик © (2006-07-04 17:15) [37]

> Игорь Шевченко © (04.07.06 17:13) [35]
> Пусик © (04.07.06 16:43) [27] > Вместо конкретного опровержения
> опять словоблудие.Да сдалось ты мне - опровергать тебя.
> Таблеток от хамства побольше купи, ламер.

Спасибо на добром слове, модератор.

Просьба не соваться больше в подобные ветки, так как пользы от тебя в них нет, а только попытки с высоты своего положения давить на других.

← →
Пусик © (2006-07-04 17:17) [38]

> Более того, я могу навернуть в него любую функциональность,
> и он все равно будет вести себя одинаково.

Сомневаюсь насчет любой функциональности.

← →
DrPass © (2006-07-04 17:19) [39]

> Пусик © (04.07.06 17:17) [38]
>
> Сомневаюсь насчет любой функциональности

Игорь Шевченко в отношении вас прав на 100% :-)

← →
Пусик © (2006-07-04 17:25) [40]

> И какие мне нужны усилия, чтобы это объект вел себя неодинаково
> в зависимости от создавшего его потока?

TMyClass=class Canvas: TCanvas: // и т.д. end;

← →
Пусик © (2006-07-04 17:29) [41]

> > Игорь Шевченко © (04.07.06 17:13) [35]

За пост [24] прошу прощения, конечно. Но не более того.
Хочу заметить, что букварь используют по назначению не только ламеры и чайники.
За сим можно закончить.

← →
begin...end © (2006-07-04 17:30) [42]

> Пусик © (04.07.06 17:25) [40]

Ок, прекрасно. Итак, СОЗДАЁМ два экземпляра TMyClass в РАЗНЫХ потоках -- основном и дополнительном. Теперь ОБРАЩАЕМСЯ к этим объектам из ОДНОГО потока (главного).

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

← →
Пусик © (2006-07-04 18:19) [43]

> begin...end © (04.07.06 17:30) [42]
> > Пусик © (04.07.06 17:25) [40]Ок, прекрасно. Итак, СОЗДАЁМ
> два экземпляра TMyClass в РАЗНЫХ потоках -- основном и дополнительном.
> Теперь ОБРАЩАЕМСЯ к этим объектам из ОДНОГО потока (главного).
>

Не пойдет.
Обращение к объекту должно быть из того потока, в котором он создан.

← →
DrPass © (2006-07-04 18:21) [44]

> Пусик © (04.07.06 18:19) [43]

Delphi под рукой есть? Попробуй, а?

← →
Пусик © (2006-07-04 18:35) [45]

> DrPass © (04.07.06 18:21) [44]
> > Пусик © (04.07.06 18:19) [43] Delphi под рукой есть?
> Попробуй, а?

Попробовать что?

← →
begin...end © (2006-07-04 18:38) [46]

> Пусик © (04.07.06 18:19) [43]

Это почему же "не пойдёт"?

Разве к объекту можно обращаться только из потока, в котором объект был создан? Вовсе необязательно.

Вы в [40] привели пример класса, экземпляры которого, по-Вашему, будут себя вести по-разному в зависимости от того, в каком потоке они созданы? Привели.

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

← →
Пусик © (2006-07-04 18:45) [47]

> begin...end © (04.07.06 18:38) [46]
> > Пусик © (04.07.06 18:19) [43]Это почему же "не пойдёт"?
> Разве к объекту можно обращаться только из потока, в котором
> объект был создан? Вовсе необязательно.Вы в [40] привели
> пример класса, экземпляры которого, по-Вашему, будут себя
> вести по-разному в зависимости от того, в каком потоке они
> созданы? Привели.

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

И разговор идет именно об этом. Не надо переводить в другое русло дискуссию.

← →
DrPass © (2006-07-04 18:57) [48]

> Пусик © (04.07.06 18:45) [47]

> Если объект создан в одном потоке, то странно было бы не
> использовать его именно в этом потоке. Так?

Почему это вдруг? Можно создать объект в одном потоке и без проблем использовать его в любом другом. И это абсолютно нормально кроме тех редких случаев, когда используется непотокобезопасный код. Что вам и пытаются вдолбить на протяжении полусотни постов этой ветки

← →
begin...end © (2006-07-04 18:57) [49]

> Пусик © (04.07.06 18:45) [47]

> Есть разница между созданы и используются, не так ли?

Совершенно верно. Есть.

> Если объект создан в одном потоке, то странно было бы не
> использовать его именно в этом потоке. Так?

Не имеет значения.

> И разговор идет именно об этом.

Разговор идёт о том, что, по-Вашему, объекты, СОЗДАННЫЕ в разных потоках, ведут себя (при прочих равных условиях) ПО-РАЗНОМУ. Вопрос от DrPass в [36] был задан чётко и конкретно: речь шла о месте СОЗДАНИЯ объектов, а не о месте их ИСПОЛЬЗОВАНИЯ. И Ваш ответ на него [40] тоже абсолютно конкретен.

Поэтому просьба привести ПРИМЕР, подтверждающий Вашу точку зрения. Либо признать, что в [40] (а может быть, и кое-где ранее) Вы ошибались.

← →
Пусик © (2006-07-04 19:07) [50]

> Поэтому просьба привести ПРИМЕР, подтверждающий Вашу точку
> зрения. Либо признать, что в [40] (а может быть, и кое-где
> ранее) Вы ошибались.

Пример приведен в [40].
Если есть возражения, прошу высказать.

← →
Пусик © (2006-07-04 19:12) [51]

> > Пусик © (04.07.06 18:45) [47] > Если объект создан в
> одном потоке, то странно было бы не > использовать его именно
> в этом потоке. Так?Почему это вдруг? Можно создать объект
> в одном потоке и без проблем использовать его в любом другом.
>

Можно. Но это как раз тот случай, который не имеет смысла рассматривать, потому что "Объекты просто хранятся в памяти процесса", и вне контекста потока их рассматривать не имеет смысла(учитывая тему ветки). Смысл имеет только использование объекта( в том числе и его методов) в контексте конкретного потока. Думаю, что это ясно?

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

Совершенно нормально. Но в этот случай как раз выпадает из темы обсуждения.

> Что вам и пытаются вдолбить на протяжении полусотни постов
> этой ветки

Не надо мне ничего "вдалбливать". Все это мне известно не хуже, чем тебе.
Как и begin...end, ты пытаешься увести разговор в сторону.

← →
begin...end © (2006-07-04 19:13) [52]

> Пусик © (04.07.06 19:07) [50]

Возражения есть. Экземпляры класса из [40] будет вести себя при прочих равных условиях абсолютно одинаково, независимо от того, в каком потоке они были созданы.

Однако Вы привели пример [40] в ответ на вопрос о том, в каких случаях объекты ведут себя по-разному в зависимости от того, в каком потоке они созданы.

Вот такая вот нестыковочка.

← →
begin...end © (2006-07-04 19:21) [53]

> Пусик © (04.07.06 19:12) [51]

> Совершенно нормально.

То есть как это? Только что (в [47]) Вы утверждали, что использовать объект за пределами потока, в котором он был создан -- "странно". А теперь Вы считаете это "нормальным".

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

← →
Пусик © (2006-07-04 19:36) [54]

> Вот такая вот нестыковочка.
</I
> Определитесь, пожалуйста.

>

Нет уж, это ты определись, о чем ведешь дискуссию. Либо о том, куда вы с DRPass пытаетесь пытаетесь увести разговор, либо о том, что сказано в [21]
Хочу заметить, что пост № [40] связан контекстом всей дискуссии, и с этого поста он не началась. Тогда продолжим обсуждение.

Так что соизволь не выдергивать фразы из контекста обсуждения.
Это как не стыкуется с последними требованиями о стыковочках.

← →
begin...end © (2006-07-04 19:50) [55]

> Пусик © (04.07.06 19:36) [54]

> Нет уж, это ты определись, о чем ведешь дискуссию.

Я уже давно определился. Я хочу понять, почему Вы считаете, что поведение объекта зависит от того, в каком потоке он был создан. В [40] Вы привели пример описания класса, якобы подтверждающий это. А теперь я прошу Вас првиести соответствующий пример кода, показывающий различие в поведении.

← →
Пусик © (2006-07-04 20:03) [56]

> В [40] Вы привели пример описания класса, якобы подтверждающий
> это. А теперь я прошу Вас првиести соответствующий пример
> кода, показывающий различие в поведении.

1. Еще раз прошу соизволить прочитать топик.
2. Пример в [40] был приведен именно в контексте обсуждения, а не после перевода его в сторону.

Если хочешь, могу привести и пример реализации объекта в потоке, который будет удовлетворять твоим требованиям(Заметь - не относящихся к теме топика).

← →
Пусик © (2006-07-04 20:05) [57]

И, кстати, неполохо бы узнать -

> Я уже давно определился.

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

← →
begin...end © (2006-07-04 20:09) [58]

> Пусик © (04.07.06 20:03) [56]

Прошу принять во внимание, что топик я прочитал. Причём ещё до того, как написал в него своё первое сообщение.

> Если хочешь, могу привести и пример реализации объекта в
> потоке, который будет удовлетворять твоим требованиям

ОК, будет интересно посмотреть.

← →
begin...end © (2006-07-04 20:10) [59]

> Пусик © (04.07.06 20:05) [57]

> с чем же ты все-таки определился

Я определился с тем, "о чём я веду дискуссию".

← →
Пусик © (2006-07-04 20:16) [60]

> Я определился с тем, "о чём я веду дискуссию".

И о чем же?
Выбор невелик. Прошу известить. Уже знать хочется.

← →
begin...end © (2006-07-04 20:18) [61]

> Пусик © (04.07.06 20:16) [60]

Сорри, но на Ваш вопрос я уже ответил в [55]. Повторяться не хочется.

← →
Пусик © (2006-07-04 20:41) [62]

Хочу заметить, что пример ниже лишь демонстрация того, что так жаждет begin...end ©, и является полным оффтопиком.

Темой является:
ОТЛИЧИЕ В ПОВЕДЕНИИ ОБЪЕКТОВ В ОСНОВНОМ И ДОПОЛНИТЕЛЬНЫХ ПОТОКАХ.

(Если нужно буквоедство, то в [4] недвусмысленно сказано о том, что функция автора выполняется в доп. потоке.)

Ниже пример показывает именно то, что желает видеть оппонент: Разное поведение объекта в зависимости от того, где этот объект создается.

unit Unit1; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, Unit2,OleCtrls,ComObj,ActiveX; type TForm1 = class(TForm) Button1: TButton; Button2: TButton; procedure Button1Click(Sender: TObject); procedure Button2Click(Sender: TObject); private { Private declarations } public { Public declarations } end; var Form1: TForm1; TH: TThr; implementation {$R *.dfm} procedure TForm1.Button1Click(Sender: TObject); begin TH := TThr.Create(False); end; procedure TForm1.Button2Click(Sender: TObject); begin //Обращение к объекту из основного потока. TH.Start; end; end.

unit Unit2; interface uses classes,windows,OleCtrls,ComObj,ActiveX; type TObj=class(TObject) public objIE:OleVariant; constructor Create; destructor Destroy; override; procedure Navigate; end; TThr=class(TThread) public S: String; FObj: TObj; procedure Execute; override; procedure Start; end; implementation procedure TThr.Execute; var i: Integer; begin FObj := TObj.Create; FreeOnTerminate := True; //обращение к объекту из потока, в котором создан объект. Start; Suspend; FObj.Free; end; procedure TThr.Start; begin FObj.Navigate; S := FObj.objIE.document.links.Item(0); MessageBox(0,PChar(s)," ",MB_OK); end; { TObj } constructor TObj.Create; begin inherited; CoInitialize(nil); objIE := CreateOLEObject("InternetExplorer.Application"); objIE.Visible := 0; end; destructor TObj.Destroy; begin CoUninitialize; inherited; end; procedure TObj.Navigate; begin objIE.Navigate( "http://www.yandex.ru"); while objIE.Busy do sleep(500); end; end.

Демонстрация второй части - создание объекта в основном потоке, а использование его в дополнительным - снизойди, проверь сам.

← →
DrPass © (2006-07-04 20:42) [63]

Удалено модератором

← →
Пусик © (2006-07-04 20:48) [64]

Удалено модератором

← →
Пусик © (2006-07-04 20:53) [65]

Удалено модератором

← →
Leonid Troyanovsky © (2006-07-04 20:54) [66]

Удалено модератором

← →
Leonid Troyanovsky © (2006-07-04 20:59) [67]

Удалено модератором

← →
Пусик © (2006-07-04 21:00) [68]

Удалено модератором

← →
Пусик © (2006-07-04 21:01) [69]

Удалено модератором

← →
Игорь Шевченко © (2006-07-04 21:02) [70]

Пусик © (04.07.06 21:00) [68]

Оно тебе сильно надо, а ? Остынь.

← →
Пусик © (2006-07-04 21:03) [71]

> Игорь Шевченко © (04.07.06 21:02) [70]
> Пусик © (04.07.06 21:00) [68] Оно тебе сильно надо, а
> ? Остынь.

Хорошо.

← →
begin...end © (2006-07-04 21:44) [72]

> Пусик © (04.07.06 20:41) [62]

> Темой является:
> ОТЛИЧИЕ В ПОВЕДЕНИИ ОБЪЕКТОВ В ОСНОВНОМ И ДОПОЛНИТЕЛЬНЫХ
> ПОТОКАХ.

Должен Вас несколько поправить: ТЕМОЙ является вопрос: "В чём различие между СОЗДАНИЕМ объекта в Create и в Execute потока?"

> Ниже пример показывает именно то, что желает видеть оппонент:
> Разное поведение объекта в зависимости от того, где этот
> объект создается.

К сожалению, это не то, что я желаю видеть. Во-первых, класс в Вашем примере не является классом из [40], для которого я просил иллюстрацию. А во-вторых, Вы упустили из виду существенный момент (см. [46], [49]) -- должно быть несколько объектов, и они должны находиться при прочих равных условиях. Ваш пример этому не удовлетворяет.

← →
Шпиён (2006-07-04 21:48) [73]

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

program Demo; {$APPTYPE CONSOLE} uses Classes, Windows; var Sum: Integer; Type TJOPS=class // Sum:Integer; забудем вот эту строчку написать.... //фокус-покус.... теперь будем иметь иллюзию разного поведения класса Constructor Create; procedure AddNumber(Number: Integer); function GetSum: Integer; end; Constructor TJOPS.Create; begin Sum := 0; end; procedure TJOPS.AddNumber(Number: Integer); begin Sum := Sum + Number; end; function TJOPS.GetSum: Integer; begin Result := Sum; end; type TSumThread1 = class(TThread) jops:TJOPS; Constructor Create(suspended:boolean); protected procedure Execute; override; end; type TSumThread2 = class(TThread) jops:TJOPS; protected procedure Execute; override; end; Constructor TSumThread1.Create(suspended:boolean); begin jops:=TJOPS.Create; inherited Create(suspended); end; procedure TSumThread1.Execute; var I: Integer; begin for I:=1 to 1000 do begin jops.AddNumber(1); end; WriteLn ( "Sum=", jops.GetSum ) ; end; procedure TSumThread2.Execute; var I: Integer; begin jops:=TJOPS.Create; for I:=1 to 1000 do begin jops.AddNumber(1); end; WriteLn ( "Sum=", jops.GetSum ) ; end; var I: Integer ; ThreadHandles : Integer ; T1 : TSumThread1; T2 : TSumThread2; begin T1:=TSumThread1.Create(True); T1.FreeOnTerminate := True; ThreadHandles := T1.Handle; Sum:=3; T1.Resume; WaitForMultipleObjects(1, @ThreadHandles, True, INFINITE); T2:=TSumThread2.Create(True); T2.FreeOnTerminate := True; ThreadHandles := T2.Handle; Sum:=3; T2.Resume; WaitForMultipleObjects(1, @ThreadHandles, True, INFINITE); Write("Press Enter..."); ReadLn; end.

> begin...end © (04.07.06 21:44) [72]
>Во-первых, класс в Вашем примере не является
> классом из [40],

Во-первых, я внятно и ясно сказала в [56], к чему относится тот класс. Так что не надо передергивать.

> Должен Вас несколько поправить: ТЕМОЙ является вопрос: "В
> чём различие между СОЗДАНИЕМ объекта в Create и в Execute
> потока?"

Увы, поправка уже была дана(про пост [4]). Так что не стоит мусолить пустое.

> должно быть несколько объектов, и они должны находиться
> при прочих равных условиях. Ваш пример этому не удовлетворяет.
>

Каким условиям не удовлетворяет? Можно поточнее?

Только не надо про [40]. Уже все сказано про тот пример.

Я привела пример именно по твоим требованиям.
Будь добр точно сформулировать эти требования.

> "В чём различие между СОЗДАНИЕМ объекта в Create и в Execute
> потока?

На этот вопрос ответит любой начинающий. Для этого и спор не нужен.
Ответ на этот вопрос дан был уже в

Пусик © (04.07.06 01:32) [1]

Конструктор выполняется в контексте вызывающего потока. объект, соответственно, создается в нем же. При создании в поточной функции объект "живет" в этом потоке.

> Пусик © (04.07.06 21:56) [74]

> Во-первых, я внятно и ясно сказала в [56], к чему относится
> тот класс.

Он относится к ответу на вопрос из [36].

> Я привела пример именно по твоим требованиям.

Нет.

> Пусик © (04.07.06 22:02) [75]

> При создании в поточной функции объект "живет" в этом потоке.

Что значит "живёт"?

> Что значит "живёт"?

Образное выражение.
Означает, что для работы с объектом в потоке не требуется дополнительных усилий.

> Он относится к ответу на вопрос из [36].

Давай уже будь тогда точнее?
[21]
[33]

Учитывая [42] видно, что в [42] ты резко увел туму использования объектов в потоке в сторну ИСКЛЮЧИТЕЛЬНО СОЗДАНИЯ объектов в потоке.

> > Я привела пример именно по твоим требованиям.
>Нет.

См. [74] по поводу требований.

> Пусик © (04.07.06 22:19) [77]

> Образное выражение.
> Означает, что для работы с объектом в потоке не требуется
> дополнительных усилий.

Это выражение не менее образно. Непонятно, о каких усилиях идёт речь.

> Учитывая [42] видно, что в [42] ты резко увел туму использования
> объектов в потоке в сторну ИСКЛЮЧИТЕЛЬНО СОЗДАНИЯ объектов
> в потоке.

Я ничего и никуда не уводил. Вы (а не я) в [40] отвечали примером класса на вопрос о различиях в поведении его экземпляров в зависимости от того, в каких потоках они были созданы.

> См. [74] по поводу требований.

Требования уже были сформулированы ранее.

В заключение более развёрнуто сформулирую свою точку зрения, поскольку сейчас уже поздно, а завтра участвовать в обсуждении возможности нет.

Что такое вообще экземпляр класса aka объект? Это поля, методы и свойства.

Свойства -- это механизм доступа к полям.

Что такое поля? Это часть памяти, выделенной при создании экземпляра (оставшаяся часть памяти используется для служебных целей). Относится ли эта память к какому-либо потоку? Конечно, нет. А к какому-либо экземпляру? Да, разумеется.

Что такое методы? Это набор участков кода, которые, кстати, существовали в памяти ещё до создания экземпляра. Относится ли этот код сам по себе к какому-либо потоку, или какому-либо экземпляру? Конечно, нет. Сколько бы ни работало потоков, сколько бы ни было создано экземпляров класса -- методы останутся там же, где они и были, и в том же количестве, в каком они и были.

Что происходит при создании объекта? Выделяется память для полей и служебных данных. Имеет ли значение, в каком именно потоке эта память выделилась? Нет, не имеет.

Поэтому при прочих равных условиях объекты (т.е. их поля и методы) одного и того же класса, созданные в различных потоках, друг от друга ничем не отличаются. А возможные отличия в поведении этих объектов вызваны отнюдь не различиями самих объектов, а различиями потоков, исполняющих их методы.

Кому надо -- тот поймёт.

> begin...end © (04.07.06 23:00) [79]

> целей). Относится ли эта память к какому-либо потоку? Конечно,
> нет. А к какому-либо экземпляру? Да, разумеется.

С памятью, конечно, более-менее гладко, бо она прнадлежит процессу
("контейнеру").

Ну, а как быть с тем, что принадлежит самому потоку, скажем,
окна, хуки, акселераторы и др.?

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

> отличия в поведении этих объектов вызваны отнюдь не различиями
> самих объектов, а различиями потоков, исполняющих их методы.

Ну, а если сказать, что различия объектов вызваны различием
потоков, исполняющих их методы (вкл. тот же конструктор)?
А отличия поведения вызваны, все же, различием объектов?

--
Regards, LVT.

← →
Шпиён (2006-07-05 01:04) [81]

> С памятью, конечно, более-менее гладко, бо она прнадлежит
> процессу
> ("контейнеру").

Я дико извиняюсь, но разве TLS тоже принадлежит процессу?

> [62] Пусик © (04.07.06 20:41)

Мрак. И с таким кодом бить себя в грудь "Да я, да я..."?

Кто сказал, что бесполезно
Биться головой об стену?... (с) В.Бутусов

Видимо, Бутусов не прав.

> но вот простой пример "кривого" класса, при котором будет иллюзия разного поведения

А какой смысл обсуждать кривой код? Если код написан криво, то по-разному он может вести себя при всяком новом создании объекта даже в одном потоке. :) Потому, код даже не смотрел.

← →
Шпиён (2006-07-05 10:00) [83]

> А какой смысл обсуждать кривой код? Если код написан криво,
> то по-разному он может вести себя при всяком новом создании
> объекта даже в одном потоке. :) Потому, код даже не смотрел.
>

Тебе может и нет смысла. Но, процентов на 50 в этом коде - ответ на вопрос автора ветки (см. Tonich © (04.07.06 01:46) [4] )

> Я дико извиняюсь, но разве TLS тоже принадлежит процессу?

А что имеется в виду под TLS в твоем вопросе ? Структура управления TLS, составная, часть принадлежит процессу, часть потоку

← →
Шпиён (2006-07-05 10:35) [85]

> evvcom © (05.07.06 08:58) [82]
> > [62] Пусик © (04.07.06 20:41)
>
> Мрак. И с таким кодом бить себя в грудь "Да я, да я..."?
>

Вам пора присвоить значок "мастера". Одно из качеств "только что омастеренного" уже созрело.
ps Прошу прощения у тех мастеров, которых это "заболевание" миновало. Наболело.

> Игорь Шевченко © (05.07.06 10:25) [84]

Спасибо за ответ по существу (без всякой иронии).

← →
Шпиён (2006-07-05 10:41) [86]

> > Игорь Шевченко © (05.07.06 10:25) [84]

ИМелось в виду то, что у Рихтера (гл.21) названо "Локальная память потока (thread-local storage, TLS) "
Обращаясь к TlsSetValue, поток изменяет только свой PVOID-массив. Он не может что-то изменить в локальной памяти другого потока. Лично мне хотелось бы видеть какую-нибудь TLS-функцию, которая позволила бы одному потоку записывать данные в массив другого потока, но такой нет.
(с)

> [85] Шпиён (05.07.06 10:35)

Что не понравилось? Вступать мне в пустую дискуссию не хотелось, но не высказать своего мнения не смог. Или хочешь сказать, что [62] написан нормально?

Шпиён (05.07.06 10:41) [86]

Зная внутреннее устройство TLS, можно сделать то, о чем сожалеет Рихтер, но стандартных средств, как он верно отмечает, нет, да и ни к чему они. TLS представляет из себя обычную память, доступную для чтения/записи, так как владельцем всего адресного пространства является процесс, то чтение/запись доступна всем потокам. "Локальность" памяти по отношению к потоку обеспечиватся использованием соответствующих API-функций, только и всего.

← →
Шпиён (2006-07-05 11:09) [89]

> evvcom © (05.07.06 10:58) [87]

> Или хочешь сказать, что [62] написан нормально?

Не учтена цель, с которой написан код.
[62] Выполняет свою задачу - демонстрация эффекта. Для этой цели - вполне нормален.
Так же как и мой абсолютно кривой класс выполняет свою задачу - прозрачно продемонстрировать, где может быть ошибка у автора ветки. И с этой точки зрения - тоже нормален. Хотя за такой код в реальной программе - руки бы оторвал.

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

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

> [89] Шпиён (05.07.06 11:09)

Игорь Шевченко уже ответил. Полностью поддерживаю.
А эффект из [62] можно воспроизвести и в своих примерах, но это вовсе не означает, что ЭТА кривость зарыта в IE. Кривость в том, что программистом-юзером не учтены особенности создания данного COM-объекта. Наверняка это где-то задокументировано и в [62] успешно проигнорировано.

← →
Шпиён (2006-07-05 11:36) [92]

"Это" действительно задокоментировано. В любой мало-мальски приличной лиитературе по СОМ. И в [62] "проигнорировано" намеренно

← →
Шпиён (2006-07-05 11:58) [93]

Даже не проигнорировано,а ,наоборот, учтено и правильно использовано (если не забывать про цель написания кода в [62])

← →
Шпиён (2006-07-06 11:28) [94]

Посмотрел еще раз на "дискуссию"... Подумал...
Написал простенький код...

program TLSDemo; {$APPTYPE CONSOLE} uses Classes, Windows; Type TJOPS=class WhoAmI:string; Constructor Create(Name:string); end; TThread1 = class(TThread) Constructor Create(suspended:boolean); protected procedure Execute; override; end; threadvar A,B:TJOPS; Constructor TJOPS.Create(Name:string); begin WhoAmI := Name; end; Constructor TThread1.Create(suspended:boolean); begin inherited Create(suspended); A:=TJOPS.Create("A"); end; procedure TThread1.Execute; begin B:=TJOPS.Create("B"); Writeln("InThread:"); if Assigned(A) then Writeln(A.WhoAmI) else Writeln("A not assigned"); if Assigned(B) then Writeln(B.WhoAmI) else Writeln("B not assigned"); while True do sleep(1); end; var T1 : TThread1; begin Writeln("TLS Demo"); T1:=TThread1.Create(True); T1.FreeOnTerminate := True; T1.Resume; WriteLn("OutThread: "); if Assigned(A) then Writeln(A.WhoAmI) else Writeln("A not assigned"); if Assigned(B) then Writeln(B.WhoAmI) else Writeln("B not assigned"); ReadLn; TerminateThread(T1.Handle,0); end.

Результаты работы:

TLS Demo
OutThread:
A
B not assigned
InThread:
A not assigned
B

Шпиён (06.07.06 11:28) [94]

Возможности для кривизны кода безграничны и в отсутствие потоков...

← →
Шпиён (2006-07-06 12:44) [96]

← →
Шпиён (2006-07-06 12:47) [97]

еще можно [8] посмотреть.

> DrPass © (04.07.06 12:35) [8]
> Объект не может жить в вызывающем потоке. Поток - это не
> сущность, в которой что-либо живет, а просто состояние процессора.
> Объект находится в памяти, и он один и тот же для любого
> потока, независимо от того, где он был создан.

Шпиён (06.07.06 12:44) [96]

И чего ? Я понимаю, что буковок много, пока каждую съешь, может много воды утечь, но если ты намеренно используешь средства, предназначенные для разграничения доступа потокам, то какой смысл чему-то удивляться и доказывать, что "вот в этом случае утверждение такое-то неверно". Аналогично можно устроить поток с выборкой системных сообщений из очереди и показывать, что "на этом примере утверждение такое-то тоже не работает". Беда только в том, что к объектам, методам и их полям различное поведение, иллюстрируемое в коде, не имеет никакого отношения, а все различие обуславливается лишь конкретным поведением конкретной операционной системы в конкретных случаях.

"Поэтому при прочих равных условиях объекты (т.е. их поля и методы) одного и того же класса, созданные в различных потоках, друг от друга ничем не отличаются. А возможные отличия в поведении этих объектов вызваны отнюдь не различиями самих объектов, а различиями потоков, исполняющих их методы."

Убери особенности реализации методов и(или) полей, и вся иллюстрация пропадет.

← →
Шпиён (2006-07-06 14:11) [99]

> Игорь Шевченко © (06.07.06 13:42) [98]

Я не удивлен.

А разве в сообщении [8], [11] или [36] были указаны какие-то исключения и "прочие равные условия"?
Более того,в [11] "поток с выборкой системных сообщений из очереди" назван "единственным условием".

← →
Шпиён (2006-07-06 14:18) [100]

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

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

Шпиён (06.07.06 14:18) [100]

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

← →
Шпиён (2006-07-06 14:37) [102]

> Пусик © (04.07.06 22:19) [77]
>
> > Что значит "живёт"?
> Образное выражение.
> Означает, что для работы с объектом в потоке не требуется
> дополнительных усилий.

> Игорь Шевченко © (06.07.06 14:28) [101]

Учет тех самых особенностей - и есть "дополнительные усилия". IMHO.

Не вижу смысла продолжать.

> Не вижу смысла продолжать.
УРА!

Шпиён (06.07.06 14:37) [102]

> Не вижу смысла продолжать.

Буковки все съедены ? :)

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

← →
Шпиён (2006-07-06 15:01) [105]

> Так почему бы не привести нормальный код и не проанализировать
> его, вместо того, чтобы на кривых примерах пытаться что-
> то доказать ?

Анализируй "генофонд" Delphi.
Мне на работе за написание анализа денег не заплатят.
Нормальный код имеет весьма приличный объем.

> Буковки все съедены ? :)

Не смешно. Хамские шуточки оставь себе.

Создание обекта в потоке (Thread) Найти похожие ветки