Indy IdTCPDemo

← →
Arty (2005-05-29 00:22) [0]

В примере IdTCPDemo из дистрибутива Indy9(http://www.projectindy.org/DemoDownloads/Indy9Demos_26Oct04.zip) в основном потоке создается копонент TIdTCPClient и из него же вызыветсяего метод WriteBuffer. Однако ReadBuffer делается в другом потоке.

Следует ли из этого сделать вывод что можно создать копонент TIdTCPClient в основном потоке и вызывать метод WriteBuffer из разных потоках без допольнитнльной синкронизации ?

← →
Eraser © (2005-05-29 00:28) [1]

Arty (29.05.05 00:22)

В принципе разницы нету, где создавать. Только вот обращения к этому объекте надо защещать объектами синхронизации...

← →
Arty (2005-05-29 00:30) [2]

Тогда почему в этом приере это не делаетсяю Он как бы сделан и проверен разработчиками Indy?

← →
Eraser © (2005-05-29 00:33) [3]

Arty (29.05.05 00:22)

Я это пример если и видел, то давно... щас скачивать не буду, т.к. у меня он всё равно не откомпилится, т.к. у меня щас Indy 10 установлена.

Я не совсем понимаю из КАКОГО компонента вызывается ReadBuffer?
Опиши проблему поподробнее, желательно с исходником )

← →
Arty (2005-05-29 00:52) [4]

Есть мултипоточное приложение в котором некоторые потоки должны писать в одно то тоже сокет соединение (TIdTCPClient). Да и чтение из этого соеденениия тоже хочется вынести в отдельный поток. Начал делать все это с синкронизацией но вдруг наткнулься на этот пример. Там еще написанно:

Demonstration on how to use TIdTCPServer and TIdTCPClient
with using Threads and WriteBuffer/ReadBuffer.

← →
Eraser © (2005-05-29 13:11) [5]

Arty (29.05.05 00:52) [4]
Есть мултипоточное приложение в котором некоторые потоки должны писать в одно то тоже сокет соединение (TIdTCPClient). Да и чтение из этого соеденениия тоже хочется вынести в отдельный поток.

TIdTCPServer - это отдельная история, там событие OnExecute итак выполняется в отдельном потоке.
Что касается TIdTCPClient, то используй стандартные методы синхронизации, такие как критические секции например.

← →
Arty (2005-05-29 16:18) [6]

>>Что касается TIdTCPClient, то используй стандартные методы
>>синхронизации, такие как критические секции например.
это я и сам понимаю :).

Вопрос был именно про этот пример.
Я даже для експеримента сделал так:
1. Создал TIdTCPClient в основном потоке и сделал конект
затем стартовал доп. в котором делается чтение из этого же
соединения (точно так же как в примере)
2. Создал еще 3 доп. потока которы одновременно писали(много раз) в это соединение.

И как ни странно все это работало - ниакаких AV или что-то еще.
Может это предусмотренно в компоненте? Хотя насколько я понял просматривая исходники никакой синкронизации там нет.

← →
Arty (2005-05-29 19:16) [7]

Вот что нашел на форуме http://apps.atozed.com/ENWebForums/intraweb.aspx/EXEC/9/0hu76yi1bkv6fi17d64rp0pz2hgy :

"Sergey Croitor" <serg@abadonstudio.com> wrote in
news:777777CF92C6E240serg@abadonstudio.com:
> Is it correct to execute IdTcpClient.WriteStream in one thread while doing
> IdTcpClient.ReadStream in other thread at the same time?

Yes.

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

← →
Arty (2005-05-29 20:27) [8]

Вот еще:
"Prem" <prem_removeforspam@hotmail.com> wrote in message
news:3FAB1C3E.9090500@hotmail.com...

> I"m just wondering if the TIdTCPClient is threadsafe?

Yes, just like the rest of Indy is. Idy was designed for threading.

> I would like to design my application so that I have a
> "receive" thread that receives data and the main thread
> sending data.

That will work just fine. In fact, that is how the Indy server components
work.

> In your opinion, where would it be better for the IdTCPClient to be
> created? In the receive thread, or in the main thread? Does this matter?

Not really. Either way, the reading methods would be called from one
thread, and the writing methods from another. It doesn"t really matter what
the component instance itself resides, since it is going to be accessed by
multiple threads either way.

Gambit

← →
Arty (2005-05-29 20:32) [9]

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

← →
Eraser © (2005-05-29 20:40) [10]

Arty (29.05.05 20:32) [9]

Можно! Я это написал в [1].

← →
Arty (2005-05-29 20:48) [11]

Eraser © (29.05.05 20:40) [10]
так в том и дело что тут ([9]) получается не надо никакой синкронизации. Это очень хорошая внщь получается.

Arty (29.05.05 20:48) [11]

Насчёт не надобности синхронизации я сомневаюсь... тут надо глянуть исходник инди.

А синхронизировать всё равно надо... вообще я себе слабо представляю кучу потоков, половина из которых считывает данные из сокета, другая записывает данные в ЭТОТ же сокет.

Опиши для чего тебе это всё надо. Имхо алгоритм заведомо ошибочный.

← →
Arty (2005-05-30 10:18) [13]

Ты не понял. Не куча потоков.
Вызов методов чтения в одном потоке а вызов методов записи - в другом. То есть 2 потока.
Это так утверждает и раработчик Indy. И это на самом деле очень удобно в некоторых случаях.

← →
Arty (2005-05-30 10:49) [14]

Если кому еще интересно вот ответ который полностью отвечает на мой вопрос (заданный еще в ELKNews Web Forums ):

> Dear Mr. Chad Z. Hower,
> Please explain me more detailed (if it is possible) this feature.
> It is possible to create an instance of TIdTcpClient in main thread, to
make here connection to server and to start additional thread in order to
read incoming data.
> And in the same time to write simultaneity in the same connection from
other additional threads without any additional synchronization?
> (It is necessary for multithreaded application server that must write some
data in one TCP connection).
>

While Chad is not around, I can say that the read/write TCP streams are
independent and can be accessed from different threads. It"s fine, for
example, for a read thread to make one of the blocking read calls while the
main thread makes write calls.

Note that only one thread can make a blocking read call and only one thread
should be allowed to make write calls. If more than one thread needs to
write, (eg. if the read thread needed to "echo" chars by writing them back,
as well as the main thread writing stuff), the write method needs
protection. This is easily applied with a critical section.

If a read thread is used, it is common to create the TidTCPClient in the
thread constructor, rather than in the main thread. If a thread is going to
be used for something, it makes sense to encapsulate the "something" in the
thread, rather than involving the main thread in creating stuff it does not
need to.

Rgds,
Martin

Arty (30.05.05 10:49) [14]

Это я понимаю. Проблема в том, что данные передаются/принемаются по определённому протоколу. Соответственно чтение/запись должны быть согласованы, при этом не столь важно в одном они потоке или в разных.

← →
Arty (2005-05-30 13:01) [16]

Eraser © (30.05.05 12:50) [15]
Естественно.
Меня очень интересовал именно этот момент с разделением (физически) чтения и записи на 2 разных потока. Я не очень точно выразился изначально но именно это меня очень интересовало (еси уже нужно запись из многих потоков то здесь уже можно без проблем их синкронизировать - именно запись).

А уже дальше организация коректной работы использованого протокола общения с сервером - не проблема.

В любом случае спасибо за общение :), помогло понять данную особеность.

Indy IdTCPDemo Найти похожие ветки