Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Java sockets: can you send from one thread and receive on another?

Tags:

java

sockets

This is probably an extremely basic question but I'm having difficulty finding an answer.

Is it ok to have one thread writing to a Socket's output stream while another thread is reading from the Socket's input stream?

Edit: This is a client application that is speaking to an external server. I am not trying to make the two threads talk to each other. Sorry for the ambiguity.

like image 583
jfritz42 Avatar asked Dec 09 '11 17:12

jfritz42


2 Answers

Assuming you mean the threads are using the same socket to communicate with an external actor and not with each other, this is pretty common as you often don't want to block while waiting to read from the socket.

Thread1:

block on read
on recieve message - do something

Thread2:

do things
on something happening - write to socket

If instead you meant just having two threads communicate internally, you should look into non-socket alternatives.

Edit: Also beware of potential concurrency issues, so check whether the streams you are using are thread safe.

like image 95
Thomas Avatar answered Sep 30 '22 05:09

Thomas


People are confused by your question, and that's why half are saying "Yes, but that's not how two threads should communicate with each other", and the other interpret your question as being "I want one thread always writing to the socket, and another thread always reading from the socket so my program can send and receive simultaneously." The later interpretation means those two threads are NOT using the socket to exchange information with each other, but another machine which makes this less icky. The answer is YES. Sockets are bidirectional so you can be sending and receiving data at the same time. That doesn't mean you have to use two threads to do this.

Now, this is highly unusual. Of all the time I've worked on socket protocols (POP, IMAP, HTTP, etc) I've never run into a situation where this was the case, or said another way, I've never seen a protocol that demands this occur. At some point the protocol is synchronous and one of those ends has to wait before it sends more info or reads more info. The only case I could think of is something like RTMP, Audio, or Video streaming. However, I think most of those use some form of non-blocking IO so simulate simultaneous communication.

And that's the next thing you might want to consider. When you are processing messages from the socket you might check the socket for data before blocking on it. If it's there read it in, if you have data to write check and see if you can write without blocking, then write it. Or use non-blocking IO sockets. That way you only have a single thread reading/writing to a socket and sync'ing between reads/writes is a no brainer. With threads you are going to have to use locking or semaphores or something to coordinate between them and that could lead to dead locks.

like image 45
chubbsondubs Avatar answered Sep 30 '22 06:09

chubbsondubs