Как правильно организовать слушающий и отвечающий потоки?

[CRobin]

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

Добавлено спустя 37 минут 8 секунд:
Например есть класс-поток TSend, он порождает еще два потока recv и log.

Код: Выделить всё

  TSend = class(TThread)
    recv : TThread;
    config : TConfig;
    log  : TLog;;
  protected
    constructor Create;
    procedure Execute; override;
  end; 

Как сделать чтоб из потоков recv и log было доступны свойства родителя TSend ?

[alexs]

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

[CRobin]

Я имел в виду, что из потока recv не получается получить данные из config, например.

[MysticCoder]

пусть TSend при порождении TLog и TRecv передает им ссылку на себя, типа log := TLog.Create(Self), а тот уже внутри сохраняет эту ссылку для своего пользования. но с критическими секциями осторожнее, если юзаешь блокирующие сокеты и одну и ту же секцию, то recv займет секцию и будет долго ждать пока ему че нить придет, а ему ничего не придет пока Send что нибудь не отправит на сервер, а он как раз будет ждать пока эта секция не освободится

Асинхронный сокет в одном потоке, имхо, лучше. А то на сокет больше одного потока это как то чревато непредвиденными ошибками.

[stanilar]

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

Думается мне что тут еще понадобится третий поток по работе с портом, а заодно управляющий порядком чтения/записи.

IMHO
Очень странное желание - разнести ЛОГИКУ по потокам. Обычно в поток выносят код работы с железом, потому как именно он дает задержки в выполнении программы. Т.е. нужен всего один поток, работающий с портом.

З.Ы. Да и может нафиг эти потоки? В делфе был прекрасный компонент - ICS, прекрасен он именно своей асинхронностью и событийностью, что позволяет работать без потоков. Думается что и под лазарь есть что-то подобное.

[yeger]

Я не большой специалист, но есть опыт по сокетам TCP. Внесу свои 5 копеек.

Потоки нужны, да, потому что любые тормоза связи очень пагубно сказываются на приложении, все виснет и залипает, если это не выведено отдельным потоком. Особенно если не используете уже проверенную http://wiki.freepascal.org/lNet библиотеку, например под андроид пишете.

Для чего разносить получение и отправку я не понимаю, если сервер - то слушать и при коннекте отправлять и получать в сокет, если клиент - коннектится и тем же образом работать. Вы на обоих сторонах будете и сервер и клиент держать? А как с номером порта тогда? Он не может же быть и сервером и клиентом одновременно вроде. Какие-то кластеризованные сервера делаете?

Как я обошел (как раз про андроид речь, делал из телефона мышку на комп): Мысль трогать родителя (основной поток) из фоновых потоков мне в голову не приходила, я подумал что родительский поток должен сказать что то типа "соединись, слушай порт и если что передавай полученное мне", а подчиненный поток маниакально должен проверять доступность и возвращать если что-то получено в главный, ну и об ошибках говорить. Только клиент сокет - сервер у меня на компе там lnet с отлично реализованным серверным сокетом.
Написал свой вариант объекта сокета, где расписал все про получение и отправку данных. Это кстати позволяет не в потоке отладить. У меня проблемы с отладчиком в потоках (((. Потом сделал объект поток, который с этим сокетом работает, а его уже обернул в объект клиент-сокет наследник первого сокета но с потоком внутри.

Объяснил несколько путанно, но могу выложить модуль почитать. Надо?

[CRobin]

пусть TSend при порождении TLog и TRecv передает им ссылку на себя, типа log := TLog.Create(Self)

Так сделать не получилось, поскольку класс TSend еще небыл объявлен на молмент объявления TLog, но получилось сделать через указатели. Спасибо за совет.