Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Readers, writers, and blocking

 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
<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...
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I goofd. Would the moderator please move this post to Threads?
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just realized where these can be useful. Say you have more than one writer that writes to the same stream, from different threads:
<code><pre>
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");
}
};

t1.start();
t2.start();
}
</pre></code>
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>
or
<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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic