Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #8367

Re: Blocking IO thread-per-connection model: possible to avoid polling?

Show all headers | View raw

On 9/26/11 10:52 PM, Giovanni Azua wrote:
> Hello Pete,
>
> Please note I am using classic Socket and Blocking IO and not NIO.
>
> On 9/27/11 12:22 AM, in article
> <NpOeStPeAdM@NnOwSlPiAnMk.com>  wrote:
>>
>> Why do you need to interrupt the thread in order to send data?  You
>> should be able to just get the output stream from the socket when you
>> create it, and then use that any time you want to send data.
>>
> Any time I want? Even if it means to write to the OutputStream from a
> different thread than the one receiving data? It is not clear from the
> documentation I can do this safely on a Socket. I think is not possible
> unless I get the underlying SocketChannel or?

I agree that the documentation is not clear on this point.  However, it 
is a fundamental criteria for BSD sockets and any API inherited from 
them that sockets be thread-safe and full duplex.  Java sockets are the 
same.

You would not want to use the same InputStream simultaneously from 
multiple threads, nor the same OutputStream simultaneously from multiple 
threads, but reading from one thread and writing from another is fully 
supported.  The Java sockets API would be broken if it weren't.

>> The thread that reads from the socket shouldn't need to be responsible
>> for sending at all (except possibly as an optimization in the case where
>> it knows right away it has something to send as a response to something
>> it's just read).
>>
> I would not like to have my "Worker Threads" IO bound in any way, I would
> not prefer to have them responsible for sending data. The other idea is two
> have two-threads-per-connection model, one for receiving and one for sending
> .... but this is not the model I was trying to implement in my OP.

You will need to do performance measurements to determine the 
best-performing architecture.  However, I will point out that your i/o 
threads are all i/o bound on the same resource: your network adapter. 
There is overhead in handing work off to other threads from a main 
"traffic cop" thread (such as your worker threads waiting on received 
data) and it's entirely possible that overall latency would be _better_ 
if you avoided that overhead by simply having the main worker threads 
handling at least some of the i/o (i.e. that i/o which can easily be 
determined immediately, rather than requiring some lengthy processing).

That said, your first concern should be correctness, and it's likely the 
design is easier to implement if each thread has a clear and simple duty 
to perform.  Your goal of not having the worker threads send any data at 
all is consistent with that approach and so is probably better to pursue 
at least initially.  You can always investigate potential optimizations 
later.

Pete

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Blocking IO thread-per-connection model: possible to avoid polling? Giovanni Azua <bravegag@hotmail.com> - 2011-09-27 00:09 +0200
  Re: Blocking IO thread-per-connection model: possible to avoid polling? Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-09-26 15:22 -0700
    Re: Blocking IO thread-per-connection model: possible to avoid polling? Robert Klemme <shortcutter@googlemail.com> - 2011-09-27 07:49 +0200
    Re: Blocking IO thread-per-connection model: possible to avoid polling? Giovanni Azua <bravegag@hotmail.com> - 2011-09-27 07:52 +0200
      Re: Blocking IO thread-per-connection model: possible to avoid polling? Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-09-27 09:29 -0700
        Re: Blocking IO thread-per-connection model: possible to avoid polling? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-09-27 10:23 -0700
        Re: Blocking IO thread-per-connection model: possible to avoid polling? Giovanni Azua <bravegag@hotmail.com> - 2011-09-29 22:21 +0200

csiph-web