Win a copy of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams this week in the Reactive Progamming forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

Multiple Threads accessing Single System.in()

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have the following two code snippets :

1.


and

2.



As you can see the first class is creating 4 threads that are simultaneously reading from the same stdin.
As they are using BufferedReader.readLine() to read from, only one thread
must be able to read at any given time(as readLine waits() till it receives a input ).

So after entering some text into the console only one of the threads must read it. So the expected output must be
Expected:
Reader One: .Starting Console Reader .....
Reader Two: .Starting Console Reader .....
Reader Thr: .Starting Console Reader .....
Reader Fou: .Starting Console Reader .....
12
Reader One: reads : 12
45
Reader Thr: reads : 45


but the actual output is
Reader One: .Starting Console Reader .....
Reader Two: .Starting Console Reader .....
Reader Thr: .Starting Console Reader .....
Reader Fou: .Starting Console Reader .....
12
Reader Two: reads :
Reader One: reads : 12
45
Reader Fou: reads :
Reader Thr: reads : 45


So, why does the second thread come out of wait() ? As in what is happening here ?
I am finding it difficult to even ask the right questions.

Could some one unravel this behaviour
 
Ranch Hand
Posts: 43
Netbeans IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I executed the same code & got the following (expected) output:

run:
Reader One: .Starting Console Reader .....
Reader Thr: .Starting Console Reader .....
Reader Fou: .Starting Console Reader .....
Reader Two: .Starting Console Reader .....
12
Reader Thr: reads : 12
33
Reader Thr: reads : 33
45
Reader Thr: reads : 45
5
Reader Fou: reads : 5
7
Reader Fou: reads : 7
8
Reader One: reads : 56
a
Reader Two: reads : a
g
Reader Two: reads : g

set up:
Java - jdk1.6.0_18
IDE - Netbeans
OS - Windows XP SP 2

Executing the code multiple times yields the same result.
Am unable to reproduce the output you have listed.

Let me know if you can reproduce it successfully.
If so, let me know your software setup.
 
tihom ujar
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi my setup was
jdk1.5_11
IDE : eclipse3.3
OS : win xp sp3

I tried the application independent of eclipse though good old command prompt . Works well now .. Thinking might be something to do with eclipse.
Will try a few other PnC's to see. thanks for the reply though would never have doubted by environment otherwise .
thanks ..
 
Sheriff
Posts: 21803
104
Eclipse IDE Spring VI Editor Chrome Java Ubuntu Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You expect that the calls to readLine() are atomic. That's an assumption I wouldn't dare make. Fortunately that's easily remedied by putting the readLine() calls in a synchronized block:
Because all threads use the same BufferedReader the calls to readLine() are now guaranteed to not interweave.
 
sarvesh meens
Ranch Hand
Posts: 43
Netbeans IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Thread-safety of readLine was the first thing on my mind when I came across this post.
Digging in to the source yielded the following snippet from BufferedReader:



readLine in BufferedReader is thread-safe, so are most of the other methods in the class.
But nothing is mentioned in the API doc about thread-safety.
Now the question is, how will developers get to know whether a method/class is thread-safe if it is not documented in API?
Developers will end up locking/unlocking un-necessarily which incurs a significant performance cost.
Can someone shed some light in this issue?
 
It's just a flesh wound! Or a tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!