27 June 2012

The ++ operator is not thread safe

Findbugs is great tools for analyzing java code. It can find potential bugs. One of the warnings is the VO: An increment to a volatile field isn't atomic (VO_VOLATILE_INCREMENT). It means that the ++ operator is not an atomic operation and thus not thread safe. To demonstrate this looks at this code:

public class PlusPlusOperatorThreadSaftey {
    @Test
    public void testThreadSaftey() throws InterruptedException {
        class IntegerHolder {
            private volatile int value = 0;
            private void increase() {
                value++;
            }
            private int getValue() {
                return value;
            }
        }
        
        final IntegerHolder integerHolder = new IntegerHolder();
        final int numberOfIncreasePerThread = 50;
        final int numberOfThreads = 100;
        
        ExecutorService threadPool = Executors.newFixedThreadPool(numberOfThreads);
        for (int i = 0; i < numberOfThreads; i++) {
            threadPool.submit(new Runnable() {
                public void run() {
                    for (int i = 0; i < numberOfIncreasePerThread; i++) {
                        integerHolder.increase();
                    }
                }
            });
        }
        
        threadPool.shutdown();
        threadPool.awaitTermination(10, TimeUnit.SECONDS);
        
        assertEquals(integerHolder.getValue(), numberOfIncreasePerThread *
            numberOfThreads);
    }
}
When running this code on my dual core CPU sometimes the test case passes, and sometimes I get:
java.lang.AssertionError: expected:<4998> but was:<5000>. Thus, the ++ operator is not atomic and updates can be lost.

To fix this you could add a synchronized block, but a better approach is to use an AtomicInteger like this:
class IntegerHolder {
        private AtomicInteger value = new AtomicInteger(0);
        private void increase() {
            value.incrementAndGet();
        }
        private int getValue() {
            return value.get();
        }
    }

11 June 2012

Create named "screen"s to continue work later

The Unix command screen is a great command that lets you manage your login sessions. If you for some reasons shares an account with several people or have many different contexts it is useful to crate a named screen session:

lennart@pingvinen:~$ screen -S myScreen

To list all the screens use:
lennart@pingvinen:~$ screen -list
There are screens on:
        14825.myScreen  (2012-06-11 08.15.28)   (Attached)
        14692.pts-0.pingvinen   (2012-06-11 08.13.25)   (Detached)
2 Sockets in /var/run/screen/S-lennart.
Note that  one of the screens are named (the myScreen) and one is unnamed and gets a default name.

To attach to a named screen:
lennart@pingvinen:~$ screen -r myScreen

16 April 2012

Increase of Linux IO scheduler queue size might lower performance

The blog post Linux I/O scheduler queue size and MyISAM performance explains a good way to increase performance when using Mysql and the Myisam database table engine. I have tried this an can confirm that it will increase performance for this typical application.

I have unfortunately discovered that it may not always increase the overall performance if you have other IO intensive operations besides an Mysql database running on your server. I have a system that runs both Mysql with Myisam and also a custom written database application that uses a lot (like 10000) small files to save data.

The system handles a stream of "messages". I measure performance by looking at graphs of how many messages are buffered (0 to 100000) and how many messages that has been discarded because the buffer is full.

For nr_requests = 128


For nr_requests = 10000

As seen from the graphs the configuration with default nr_requests (128) performs better. My advice is thus to benchmark if your specific application benefits an increased queue size.

09 April 2012

A free ssh client for Ipad


There are a bunch of ssh clients in Apple App Store that costs money. If your looking for a free one for Ipad the number is reduced: a search for the "ssh" and Price = "Free" yields 9 hits. Out of these 9 only 2 is and actual ssh client: zatelnet and Rove Mobile Admin Client.

Out of curiosity I tried Rove Mobile Admin Client. It's main purpose is actually not to be an ssh client, but to be a remote management tool for their commercial server software. But that doesn't matter, since the ssh client part of the app is free to use standalone. I could successfully connect to my home Linux computer:


Don't expect miracles out of this app, since it is free it is probably a lot worse than some "real" non-free ssh clients. But you can do basic things.

Pros:
  1. Can use private key for authentication
  2. Can edit files in nano (requires rather good terminal emulation and the abilities to send Ctrl sequences).
  3. Does maintain connection when you switch to another app
 Cons:
  1. Does not support UTF-8 (since Ubuntu uses this as default it can be a bit frustrating)
  2. Does not support select, copy and paste in the terminal emulation.
  3. Very slow (the time for a key press to "echo" is in the magnitude of 1 s).
  4. Can only have one open connection at a time

A side note: the app also includes an RDP client, but forget about using it, it is painfully slow.



27 March 2012

Me against the world: Singleton?

I just looked at http://www.reddit.com/r/java/comments/qpb8p/java_ee_revisits_the_design_patterns_singleton/. I find it rather interesting that the comments against Singleton have low scores and comments in favor have high scores.

This leads me to think: is it me against the world? Well at least my kind of programmer - that thinks that Singleton is a code smell - is in minority? Just to boost "my" side of argumentation let me be clear:

Don't us Singleton(s)!

I have personally had firsthand experience of inheriting a code base where Singletons was used extensively. It's a total nightmare! For me two areas stand out:
  • Writing test code for Singleton is much harder. You always have to watch out if one part of the code makes a side effect that makes your test case either false positive or false negative.
  • Converting a single threaded system into a multi threaded system just does not work with Singleton. You basically have to remove everything for it to work well and to avoid unnecessary synchronizations.

Easy java decompilation


Java Decompiler is a nice decompiler for Java. Lets try it! Here is my source code:
package se.lesc.blog;

/** This is class that shows how decompiled classes may look like */
public class DecompileExample {

    public static void main(String[] args) {
        
        String output = "";
        //Lets print out 10 Hello world
        for (int i = 0; i < 10; i++) {
            output += "Hello World\n";
        }
        System.out.println(output);
    }
}
When opening DecompileExample.class in Java Decompiler it looks like this;

As you can see it is very easy to browse related class files in the navigation pane to the right.When saving the source code to a file it will look like this:
/*    */ package se.lesc.blog;
/*    */ 
/*    */ import java.io.PrintStream;
/*    */ 
/*    */ public class DecompileExample
/*    */ {
/*    */   public static void main(String[] args)
/*    */   {
/*  8 */     String output = "";
/*    */ 
/* 10 */     for (int i = 0; i < 10; i++) {
/* 11 */       output = output + "Hello World\n";
/*    */     }
/* 13 */     System.out.println(output);
/*    */   }
/*    */ }

Things to note:
  1. The original line numbers has been added as a comment.
  2. Every original comment has been removed (it is removed in the compilation phase).
  3. The string operator += has been replaced by = output +.

24 February 2012

Set up a VNC Server on Linux

I would like to reblog this: How To Setup Linux VNC Server In 3 Minutes. It is a good guide on  how to set up a VNC Server in Linux (via command line only).

While I'm on the topic I'll make a ranking of how good different programs/technologies (I have tried) to remotely login and get a graphical interface:

  1. Microsoft RDP. This protocol is probably the best. It can handle high latency rather good. It will adapt to screen size and copy commands always work. The big disadvantage is the high price (about one Windows license per concurrent RDP session).
  2. Go Global. It is also very fast, but also comes at a price. One drawback is that is not so common.
  3. VNC. This protocol is rather okay on handle latency. One disadvantage is that the screen size is fixed during startup.
  4. X11. The worst protocol to handle latency. This can totally destroy a user experience! The big advantage is that it is free and always works.
And there is bunch more I never tried...