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

Вниз

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

 
Leonid Troyanovsky ©   (2006-07-04 23:28) [80]


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

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


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

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

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

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


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

--
Regards, LVT.


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


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

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


 
evvcom ©   (2006-07-05 08:58) [82]

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

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

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

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


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

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


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


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

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


 
Игорь Шевченко ©   (2006-07-05 10:25) [84]


> Я дико извиняюсь, но разве 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-функцию, которая позволила бы одному потоку записывать данные в массив другого потока, но такой нет.
(с)


 
evvcom ©   (2006-07-05 10:58) [87]

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

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


 
Игорь Шевченко ©   (2006-07-05 11:02) [88]

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

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


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


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

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


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


 
Игорь Шевченко ©   (2006-07-05 11:18) [90]


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


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


 
evvcom ©   (2006-07-05 11:29) [91]

> [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


 
Игорь Шевченко ©   (2006-07-06 12:24) [95]

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

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


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


> Игорь Шевченко ©   (06.07.06 12:24) [95]

см. [79].


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

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

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


 
Игорь Шевченко ©   (2006-07-06 13:42) [98]

Шпиён   (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]

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

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


 
Игорь Шевченко ©   (2006-07-06 14:28) [101]

Шпиён   (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.

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


 
Fay ©   (2006-07-06 14:38) [103]

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


 
Игорь Шевченко ©   (2006-07-06 14:41) [104]

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


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


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

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


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


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

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

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

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



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

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

Наверх





Память: 0.65 MB
Время: 0.045 c
15-1154069076
Neo Trinitron
2006-07-28 10:44
2006.08.27
Смена работы


2-1154865170
Sele
2006-08-06 15:52
2006.08.27
панель


2-1154788948
Robin Hood
2006-08-05 18:42
2006.08.27
Прилипание форм


3-1150885250
MsGuns
2006-06-21 14:20
2006.08.27
Максимальная скорость загрузки данных в таблицу


15-1154269891
Филипок:)
2006-07-30 18:31
2006.08.27
Игра





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