title: Separate threads for socket input and output
body: <p>I got assigned to work on some performance and random crashing issues of a multi-threaded java server. Even though threads and thread-safety are not really new topics for me, I found out designing a new multi-threaded application is probably half as difficult as trying to tweak some legacy code. I skimmed through some well known books in search of answers, but the weird thing is, as long as I read about it and analyze the examples provided, everything seems clear. However, the second I look at the code I'm supposed to work on, I'm no longer sure about anything! Must be too much of theoretical knowledge and little real-world experience or something. </p>
  
  <p>Anyway, getting back on topic, as I was doing some on-line research, I came across <a href="https://stackoverflow.com/questions/511552/reading-from-a-socket-not-waiting-for-input"><strong>this piece of code</strong></a>. The question which keeps bothering me is: <strong>Is it really safe to invoke getInputStream() and getOutputStream() on the socket from two separate threads without synchronization?</strong> Or am I now getting a bit too paranoid about the whole thread-safety issue? Guess that's what happens when like the 5th book in a row tells you how many things can possibly go wrong with concurrency.</p>
  
  <p>PS. Sorry if the question is a bit lengthy or maybe too 'noobie', please be easy on me - that's my first post here.</p>
  
  <p><strong>Edit:</strong> Just to be clear, I know sockets work in full-duplex mode and it's safe to concurrently use their input and output streams. Seems fine to me when you acquire those references in the main thread and then initialize thread objects with those, but is it also safe to <em>get</em> those streams in two different threads?</p>
  
  <p><strong>@rsp:</strong> </p>
  
  <p>So I've checked Sun's code and <code>PlainSocketImpl</code> does synchronize on those two methods, just as you said. <code>Socket</code>, however, doesn't. <code>getInputStream()</code> and <code>getOutputStream()</code> are pretty much just wrappers for <code>SocketImpl</code>, so <em>probably</em> concurrency issues wouldn't cause the whole server to explode. Still, with a bit of unlucky timing, seems like things <em>could</em> go wrong (e.g. when some other thread closes the socket when the method already checked for error conditions). </p>
  
  <p>As you pointed out, from a code structure standpoint, it would be a good idea to supply each thread with a stream reference instead of a whole socket. I would've probably already restructured the code I'm working on if not for the fact that each thread also uses socket's <code>close()</code> method (e.g. when the socket receives "shutdown" command). As far as I can tell, the main purpose of those threads is to queue messages for sending or for processing, so maybe it's a Single Responsibility Principle violation and those threads shouldn't be able to close the socket (compare with <a href="http://www.objectmentor.com/resources/articles/srp.pdf" rel="nofollow noreferrer">Separated Modem Interface</a>)? But then if I keep analysing the code for too long, it appears the design is generally flawed and the whole thing requires rewriting. Even if the management was willing to pay the price, seriously refactoring legacy code, having no unit tests what so ever and dealing with a hard to debug concurrency issues, would probably do more harm than good. Wouldn't it?</p>