Grayger

Detecting deadlock is one of common features of Java profiling tools but I haven’t experienced the situation where those tools detect deadlock from code I wrote. In fact, deadlock is hazardous because it is difficult to predict and reproduce.

I wondered under what conditions do profilers detect deadlock and then report it, so I wrote code that reaches deadlock.

package com.grayger.deadlock;

public class SimpleDeadlocker {
        private final static Object OBJ1=new Object();
        private final static Object OBJ2=new Object();

        private final static int LOOP=100;

        public void obj1First() {
                synchronized(OBJ1) {
                        printInfo(“Hold OBJ1″);
                        synchronized(OBJ2) {
                                printInfo(“Hole OBJ2″);
                        }
                        printInfo(“Release OBJ2″);
                }
                printInfo(“Release OBJ1″);
        }

        public void obj2First() {
                synchronized(OBJ2) {
                        printInfo(“Hold OBJ2″);
                        synchronized(OBJ1) {
                                printInfo(“Hole OBJ1″);
                        }
                        printInfo(“Release OBJ1″);
                }
                printInfo(“Release OBJ2″);
        }

        private void printInfo(String info) {
                System.out.println(Thread.currentThread().getName()+” “+info);
        }

        public static void main(String args[]) {
                final SimpleDeadlocker d=new SimpleDeadlocker();
                Thread t1=new Thread(new Runnable() {
                        public void run() {
                                for(int i=0;i<loop;i++)>
                                        d.obj1First();
                                }
                                d.printInfo(“Terminated”);
                        }
                }, “OBJ1_First”);

                Thread t2=new Thread(new Runnable() {
                        public void run() {
                                for(int i=0;i<loop;i++)>
                                        d.obj2First();
                                }
                                d.printInfo(“Terminated”);
                        }
                }, “OBJ2_First”);

                t1.start();
                t2.start();
        }
}

Above example can be refactored as follows:

package com.grayger.deadlock;

public class Deadlocker {
        private final static int LOOP=100;

        static class Deadlock1 {
                private final static Object OBJ1=new Object();
                private final static Object OBJ2=new Object();    

                public void obj1First() {
                        synchronized(OBJ1) {
                                printInfo(“Hold OBJ1″);
                                synchronized(OBJ2) {
                                        printInfo(“Hole OBJ2″);
                                }
                                printInfo(“Release OBJ2″);
                        }
                        printInfo(“Release OBJ1″);
                }
        }

        static class Deadlock2 {
                private final static Object OBJ1=new Object();
                private final static Object OBJ2=new Object();

                public void obj2First() {
                        synchronized(OBJ2) {
                                printInfo(“Hold OBJ2″);
                                synchronized(OBJ1) {
                                        printInfo(“Hole OBJ1″);
                                }
                                printInfo(“Release OBJ1″);
                        }
                        printInfo(“Release OBJ2″);
                }
        }

        public static void printInfo(String info) {
                System.out.println(Thread.currentThread().getName()+” “+info);
        }

        public static void main(String args[]) {
                final Deadlock1 d1=new Deadlock1();
                final Deadlock2 d2=new Deadlock2();
                Thread t1=new Thread(new Runnable() {
                        public void run() {
                                for(int i=0;i<loop;i++)>
                                        d1.obj1First();
                                }
                                Deadlocker.printInfo(“Terminated”);
                        }
                }, “OBJ1_First”);

                Thread t2=new Thread(new Runnable() {
                        public void run() {
                                for(int i=0;i<loop;i++)>
                                        d2.obj2First();
                                }
                                Deadlocker.printInfo(“Terminated”);
                        }
                }, “OBJ2_First”);

                t1.start();
                t2.start();
        }
}

The @Override annotation added in Java5 is very useful. Recently I found out the annotation of Java6 differs from that of Java5. Java6 allows annotating a method that implements a method declared in interface with @Override whereas Java5 doesn’t allow it.

Unfortunately I couldn’t find any document on the change from java.sun.com site. Missing this issue from the release note of Java6 seems to be a mistake as http://blogs.sun.com/ahe/entry/override_snafu says.

Donald Knuth, the advocate of literate programming, gave his opinion on code reuse from an interview by Andrew Binstock

I also must confess to a strong bias against the fashion for reusable code. To me, “re-editable code” is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.

In my view, literately programmed code should be visible for every programmer through its evolution, so literate programming doesn’t cope with OCP well. I guess it is why he prefer “re-editable” code to reusable black box code. But I think benefits of information hiding can be sacrificed in no case.

Recently, I found Douglas Crockford’s blog. Although I am very interested in his articles, finding his blog took a long time since http://www.crockford.com/ doesn’t provide any link to it. Reading posts was enjoyable. I note down some impressive posts.

Introducing other’s work

• A paper, Using JavaScript as a Real Programming Language
• The Non-Designer’s Design Book

Introducing his work

• Adsafe
• Contributions to JSON

Informative but arguable (in my view)

• XML’s future in WEB : XML is on web trending down. XHTML failed to displace HTML because
  • Its client-side validation is not so beneficial.
  • It lacks security model

• Thread is evil.
• Scribe, the first trial of data-document translation, is similar to JSON. Adopting SGML and XML instead of it was a bad choice.

Security of JavaScript seems to be one of his current concerns. His recent talk shows his approaches toward the security problems.