Обращение из основного потока к дочернему.

← →
Gear (2004-08-15 02:01) [0]

Добрый день!
Имеем многопоточный сервер. Каждый поток(процесс) имеет переменную с уникальным идентификатором. Основной процесс, который создал этот дочерний процесс получает данные по сокету, которые маркируются уникальным идентификатором какого-либо дочернего процесса, которому эти данные каким-то образом основной поток должен передать. Вопрос: 1) как обратиться к созданному дочернему процессу и узнать у него значение переменной уникального идентификатора? 2) как передать полученные данные процессу, которому эти данные адресованы согласно уникальному идентификатору.

← →
Fay © (2004-08-15 02:35) [1]

Храни данные как глобальные, но защити их критической секцией

← →
TUser © (2004-08-15 02:40) [2]

Прежде всего не понятно о чем ресь - о потоках или все-таки о процессах.

← →
Fay © (2004-08-15 02:42) [3]

Блин! А я прочитал всё как о потоках 8). Пора на свалку...

← →
Gear (2004-08-15 02:44) [4]

А что возможности хранить данные свои в своём потоке нет? Хочется сделать механизм реализации сессий в сервере. На каждую сессию свой поток со своими переменными, а уже чтобы основной поток передавал конкретному потоку (по id) управляющие данные полученные от клиента инициировавшего сессию (например команда потоку с id=2345, что сессия завершилась).

← →
Gear (2004-08-15 02:47) [5]

Да,прошу прощения, это потоки. Торможу. Под UNIX бычно пишу. Там форкаю новые процессы.Потоки тоже есть, но процессы привычней. Вот сейчас под виндой на Дельфи с терминами погорячился.

← →
TUser © (2004-08-15 02:53) [6]

> А что возможности хранить данные свои в своём потоке нет?

Да, почему - можно. Создай свойства в своем наследнике TThread"а, и пользуйся.

← →
Gear (2004-08-15 02:58) [7]

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

← →
Fay © (2004-08-15 02:58) [8]

Можно сделать так (в зависимости от ситуации, конечно)...

Среди прочих событий, поток ожидает некое событие, получив которое, заполняет поля структуры, адрес которой ему передали ещё при инициализации.

Или

Все данные (мз интересуемых) доступны из всех потоков, но обращение защищается крит. секцией.

2TUser © (15.08.04 02:53) [6]

Годится только в случае использования TThread-идичей. 8)

← →
Fay © (2004-08-15 03:00) [9]

2 Gear (15.08.04 02:58) [7]
Очень странный вопрос. И Id потока, Handle потока изначально знает только вызввающий поток. 8)

← →
Gear (2004-08-15 03:11) [10]

Fay © (15.08.04 03:00) [9]
id потока-это свойство которое я назначил при его создании, а не handle. То есть создаю поток а его свойству id (id: string) присваиваю уникальное занчение (id:="IHEB245KJK24lLL"). Потом мне необходимо каким-то образом данные адресованные потоку со значением id:="IHEB245KJK24lLL" передать из основного потока. Как его найти и как ему передать или даже может, как сказать дочернему потоку, что в основной поток пришли данные адресованные тебе, забери их?

← →
Fay © (2004-08-15 03:19) [11]

2 Gear (15.08.04 03:11) [10]
HANDLE CreateThread( LPSECURITY_ATTRIBUTES lpThreadAttributes, // SD SIZE_T dwStackSize, // initial stack size LPTHREAD_START_ROUTINE lpStartAddress, // thread function LPVOID lpParameter, // thread argument DWORD dwCreationFlags, // creation option LPDWORD lpThreadId // thread identifier );
Последний параметр - весьма уникатьный идентификатор потока 8).
Чем он не подходит?
И чем не подходят варианты, предложенные ранее? Если что-то не ясно - просто спроси.

З.Ы.
Как именно ты создаёшь потоки?

← →
Fay © (2004-08-15 03:39) [12]

Ёжик задумался...

← →
Юрий Зотов © (2004-08-15 07:48) [13]

Если потоки сделаны, как потомки TThread, то кто мешает ввести нужные свойства прямо в класс? Тогда, зная ссылку на экземпляр потока, сразу получаем (или устанавливаем) значения его свойств, а ссылки эти можно хранить, например, в TThreadList (для поиска нужного потока по его ID).

Кстати, зачем назначать свой ID, если у потоков и так уже есть уникальные ID и Handle?

← →
Gear (2004-08-15 12:35) [14]

Потоки сделаны как потомки TThread. Идея примерно понятна. Работа с ссылками. Ссылки хранить в списке.

Свой ID- это необходимый для меня параметр на основании которого должна вестись сессия. Это собственно реализация протокола и его Finite State Machine. Конечно можно тогда сделать соответствие "id потока - моего id".

Почему-то я первый раз слышу о TThreadList :( Есть ли у кого примеры по работе с этим списком?

← →
Gear (2004-08-15 12:40) [15]

To: Fay ©, Юрий Зотов ©

Если не сложно, пожалуйста, приведите небольшой примерчик как решить мою задачу с учётом, что потоки сделаны как потомки TThread?
Зарание спасибо!

> Gear (15.08.04 12:40) [15]

interface

type
TMyThread = class(TThread)
private
FID: Integer;
... // другие поля
protected
procedure Execute; override;
public
constructor Create(CreateSuspended: Boolean);
destructor Destroy; override;
property ID: Integer read FID write FID;
... // другие свойства
end;

function FindThread(ID: Integer): TMyThread;

implementation

var
ThreadList: TThreadList;

function FindThread(ID: Integer): TMyThread;
var
i: Integer;
begin
Result := nil;
with ThreadList, LockList do
try
for i := 0 to Count - 1 do
if TMyThread(Items[i]).ID = ID then
begin
Result := TMyThread(Items[i]);
Break
end
finally
UnlockList
end
end;

constructor TMyThread.Create(CreateSuspended: Boolean);
begin
inherited;
ThreadList.Add(Self)
end;

destructor TMyThread.Destroy;
begin
ThreadList.Remove(Self);
inherited
end;

initialization
ThreadList := TThreadList.Create
finalization
ThreadList.Free
end;

> Юрий Зотов © (15.08.04 15:06) [16]
> with ThreadList, LockList do

Это написано лишь для вызова метода и чтобы избежать доп. begin/end или я что-то не понял?

Если так - то прикольно %) Зяпятая в Си - привычно, а тут...

> KSergey © (15.08.04 20:27) [17]

Да, для краткости. LockList и UnlockList относятся к ThreadList, а Count и Items - к LockList.

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

← →
Gear (2004-08-16 00:07) [19]

Спасибо мастера. Всё срослось! Премного благодарен.

2 KSergey © (15.08.04 20:27) [17]
Неужели ни разу раньше не встречал такую запятую?
По моему - очень часто встречаемая конструкция. Чаще всего, имхо, с компонентами, которые имеют свойство типа TStrings.
Например очень часто удобно работать с конструкцией типа:
with MyComboBox, Items do ...

> [20] Германн © (16.08.04 02:44)
> [18] Юрий Зотов © (15.08.04 21:54)

Не, про запятую в with конечно знал. Тут несколько иная находка меня удивила: ведь LockList в данном случае не просто объект, к свойствам которого мы хотим обращаться без дополнительной спецификации (ну может в терминах не очень корректно, но, надеюсь, все поняли), но вызов метода! Т.е. если бы даже не было необходимости в смене области видимости (ой, запутаюсь я в терминах), то сам вызов этого LockList здесь - уже интересен...

Впрочем, это я так, от темы отступил.

> KSergey © (16.08.04 07:15) [21]

Да, конструкция не часто встречаемая. Но вполне корректная.
with ThreadList, // Здесь область видимости УЖЕ сменилась // и никто не запрещает вызвать метод. LockList do // Вызвали, получили неявную ссылку на объект // и область видимости сменилась еще раз.

Обращение из основного потока к дочернему. Найти похожие ветки