Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Programming Java threads in the real world, Part 8

Threads in an object-oriented world, thread pools, implementing socket 'accept' loops

By Allen Holub, JavaWorld.com, 05/01/99

Page 4 of 5

An alternative to the solution in Listing 1 would be to encapsulate the code from the instance initializer in a nonstatic method, and then call it when initializing the field:

new Thread()
{   int     length; 
    byte[]  copy = init();
    private void init()
    {   length        = Flush_example.this.length;
        byte[] copy   = new byte[length];
        System.arraycopy(Flush_example.this.buffer, 0, copy, 0, length);
        Flush_example.this.length = 0;
        return copy;
    }
    //...
}

This isn't much of an improvement over the instance initializer in clarity, and initializing length as a side effect of the init() call is particularly hideous. I've used arraycopy() rather than clone because I didn't want to mess with the CloneNotSupportedException. Exceptions are not allowed to propagate out of instance initializers.

Whatever method we use for initialization, the inner-class's construction happens in the new() on line 20 of Listing 1, while the outer-class object is locked, so the copy operation is thread-safe. The newly-created thread then acquires the writer lock and writes to the file in its own good time, using the copy for this purpose.

01  
02  
03  
04  
05  
06  
07  
08  
09  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  

import com.holub.asynch.Reader_writer;
import java.io.*;
class Flush_example
{
    public interface Flush_error_handler
    {   void error( IOException e );
    }
    private final OutputStream  out;
    private Reader_writer       lock = new Reader_writer();
    private byte[]              buffer;
    private int                 length;
    public Flush_example( OutputStream out )
    {   this.out = out;
    }
    //...
    synchronized void flush( final Flush_error_handler handler )
    {   new Thread()
        {   int     length; 
            byte[]  copy;
            {   length = Flush_example.this.length;
                copy   = new byte[length];
                System.arraycopy(Flush_example.this.buffer, 0, copy, 0, length);
                Flush_example.this.length = 0;
            }
            public void run()
            {   try
                {   lock.request_write();
                    out.write( copy, 0, length );
                }
                catch( IOException e )
                {   handler.error(e);
                }
                finally
                {   lock.write_accomplished();
                }
            }
        }.start();
    }
}

An exceptional problem
The next perplexing issue is what to do with the IOException. Back in the original version of the code, the exception propagated out of the flush() method to whomever called flush(). We can't do that here, because there's nobody to propagate it to -- if you start backtracking down the call stack, you'll end up back in run(), but you didn't call run(); the system did when it fired up the thread. Simply ignoring the write error, as I've been doing, isn't a good strategy for obvious reasons.

One solution to this problem is the Observer pattern discussed in March. (AWT's listeners, for example, are observers.) The method that finally catches the IOException must be a method that calls flush(), either directly or indirectly, so this method could simply register a listener and be notified when something goes wrong. In the current situation, a full-blown observer is something of an overkill, however. After all, there will only be one observer for a given I/O operation.