[ Pobierz całość w formacie PDF ]
.[ Add Comment ]The array of Blockable referencesb is not initialized at its point of definition because the piped streamscannot be set up before that definition takes place (the need for the tryblock prevents this).///:Continuing/////////// Testing Everything ///////////public class Blocking extends JApplet {private JButtonstart = new JButton("Start"),stopPeekers = new JButton("Stop Peekers");private boolean started = false;private Blockable[] b;private PipedWriter out;private PipedReader in;class StartL implements ActionListener {public void actionPerformed(ActionEvent e) {if(!started) {started = true;for(int i = 0; i < b.length; i++)b[i].start();}}}class StopPeekersL implements ActionListener {public void actionPerformed(ActionEvent e) {// Demonstration of the preferred// alternative to Thread.stop():for(int i = 0; i < b.length; i++)b[i].stopPeeker();}}public void init() {Container cp = getContentPane();cp.setLayout(new FlowLayout());out = new PipedWriter();try {in = new PipedReader(out);} catch(IOException e) {System.err.println("PipedReader problem");}b = new Blockable[] {new Sleeper1(cp),new Sleeper2(cp),new SuspendResume1(cp),new SuspendResume2(cp),new WaitNotify1(cp),new WaitNotify2(cp),new Sender(cp, out),new Receiver(cp, in)};start.addActionListener(new StartL());cp.add(start);stopPeekers.addActionListener(new StopPeekersL());cp.add(stopPeekers);}public static void main(String[] args) {Console.run(new Blocking(), 350, 550);}} ///:~In init( ), notice the loopthat moves through the entire array and adds the state andpeeker.status text fields to the page.[ Add Comment ]When the Blockable threads areinitially created, each one automatically creates and starts its ownPeeker.So you’ll see the Peekers running before theBlockable threads are started.This is important, as some of thePeekers will get blocked and stop when the Blockable threadsstart, and it’s essential to see this to understand that particular aspectof blocking.[ Add Comment ]DeadlockBecause threads can become blockedand because objects can have synchronized methods that preventthreads from accessing that object until the synchronization lock is released,it’s possible for one thread to get stuck waiting for another thread,which in turn waits for another thread, etc., until the chain leads back to athread waiting on the first one.You get a continuous loop of threads waiting oneach other and no one can move.This is called deadlock.The claim isthat it doesn’t happen that often, but when it happens to you it’sfrustrating to debug.[ Add Comment ]There is no language support to helpprevent deadlock; it’s up to you to avoid it by careful design.These arenot comforting words to the person who’s trying to debug a deadlockingprogram.[ Add Comment ]The deprecation of stop( ), suspend( ), resume( ), anddestroy( ) in Java2One change that has been made in Java 2to reduce the possibility of deadlock is the deprecation ofThread’s stop( ), suspend( ),resume( ), and destroy( ) methods.[ Add Comment ]Thereason that the stop( ) method is deprecated is because itdoesn’t release the locks that the thread has acquired, and if the objectsare in an inconsistent state (“damaged”) other threads can view andmodify them in that state.The resulting problems can be subtle and difficult todetect.Instead of using stop( ), you should follow the example inBlocking.java and use a flag to tell the thread when to terminate itselfby exiting its run( ) method.[ Add Comment ]There are times when a threadblocks—such as when it is waiting for input—and it cannot poll aflag as it does in Blocking.java.In these cases, you stillshouldn’t use stop( ), but instead you can use theinterrupt( ) methodin Thread to break out of the blockedcode://: c14:Interrupt.java// The alternative approach to using// stop() when a thread is blocked
[ Pobierz całość w formacie PDF ]