This week's book giveaway is in the Jobs Discussion forum.
We're giving away four copies of Java Interview Guide and have Anthony DePalma on-line!
See this thread for details.
The moose likes Java in General and the fly likes Readers, writers, and blocking Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Readers, writers, and blocking" Watch "Readers, writers, and blocking" New topic

Readers, writers, and blocking

Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
<code>Reader</code> and <code>Writer</code> each have a ctor that takes an <code>Object</code> argument for use as a lock object. Could some knowledgable person discuss the implications of supplying an object for locking other than the constructed object itself? How does use of a separate object affect blocking I/O operations? Do <code>InputStream</code> and <code>OutputStream</code> lock on themselves when I/O blocks?
So much to learn, so few neurons left...
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
I goofd. Would the moderator please move this post to Threads?
Jim Yingst

Joined: Jan 30, 2000
Posts: 18671
I just realized where these can be useful. Say you have more than one writer that writes to the same stream, from different threads:
public void method() {

FileWriter fw = new FileWriter("errors.log");

Thread t1 = new Thread() {
public void run() {
BufferedWriter bw1 = new BufferedWriter(fw);
bw.writeLine("Message from thread 1");

Thread t2 = new Thread() {
public void run() {
BufferedWriter bw1 = new BufferedWriter(fw);
bw.writeLine("Message from thread 2");

This might be useful, for example, if you want to log error messages from all your threads in one file. Thread 1 uses bw1 to write a message to errors.log, and thread 2 does the same using bw2. The key is, you don't want the two messages to arrive simultaneously. You might get
<code>Message from thread 1
Message from thread 2</code>
<code>Message from thread 2
Message from thread 1</code>
but you don't want
<code>MesMsessage fagroe m tfroreadm th2
read 1</code>
which is one of many possible results if the two threads were to write simultaneously. As it happens though, you don't have to worry about this, because Java has already been designed to avoid this problem. The constructor <code>new BufferedReader(fw)</code> invokes the parent constructor <code>Reader(fw)</code>, which tells the new reader to sync on the fw object. This occurs for each of the BufferedReaders, so they both synchronize on the same fw object, and there is no way for them both to write simultaneously.
Hmmm. I'm not sure how often this sort of situation comes up. Normally it's up to the programmer to make sure that two different threads aren't trying to access the same resource simultaneously. There are plenty of other things that can go wrong in this kind of situation if the programmer isn't careful. It just so happens that Java is able to prevent some of them though this design.
To answer your last question, it doesn't look like InputStream and OutputStream & their descendants do much synchronization of their methods - and if they do, it's usually self-synchronized, not synchronized on another object.
Anyway, I'll go ahead and move this to the Threads topic and see if any new ideas pop up.

"I'm not back." - Bill Harding, Twister
I agree. Here's the link:
subject: Readers, writers, and blocking
It's not a secret anymore!