Wednesday, September 7, 2011

Java Concurrency - Barrier

In this series we will discuss different concurrent structures provided in the new Java 5 Concurrent package. We will start with a simple parallel processing concept called "barrier" that we have all studied and forgotten. By definition if there are set of independent tasks (T1..Tn) that need to fully completed to initiate another task (Tx) which is dependent on all these tasks (T1...Tn) we can synchronize them using a barrier.


why is the barrier not more commonly used?
The functionality is simple enough that it can be accomplished with the low-level tools provided by Java. We can solve the coordination problem in two ways, without using a barrier.

First, we can simply have the threads wait on a condition variable. The last thread releases the barrier by notifying all of the other threads.

A second option is to simply await termination of the threads by using the join() method. Once all threads have been joined, we can start new threads for the next phase of the program

 However, in some cases it is preferable to use barriers. When using the join() method, threads are exiting and we're starting new ones. Therefore, the threads lose any state that they have stored in their previous thread object; they need to store that state prior to terminating. Furthermore, if we must always create new threads, logical operations cannot be placed together; since new threads have to be created for each subtask, the code for each subtask must be placed in separate run() methods. It may be easier to code all of the logic as one method, particularly if the subtasks are very small.

CyclicBarrier – a pair of threads computes the sum of all numbers in a
matrix by iterating over neighbour rows. Imagine you have a matrix (with an
even number of columns). You want to sum all its elements using 2 threads. The
simple way is to run 2 threads from inside main () to process rows 0 and 1, wait
(using busy-wait) until computation is complete; sum the resulting values; then
run 2 threads on rows 2 and 3, wait, sum and so on. This is demonstrated in
cyclsimple example


Below is the example:

package Barrier;
import java.util.concurrent.BrokenBarrierException;
import java.util.concurrent.CyclicBarrier;

public class CyclicBarrierExample
{
    private static int matrix[][] =
    {
        { 1 },
        { 2, 2 },
        { 3, 3, 3 },
        { 4, 4, 4, 4 },
        { 5, 5, 5, 5, 5 } };

    private static int results[];

    private static class Summer extends Thread
    {
        int row;

        CyclicBarrier barrier;

        Summer(CyclicBarrier barrier, int row)
        {
            this.barrier = barrier;
            this.row = row;
        }

        public void run()
        {
            int columns = matrix[row].length;
            int sum = 0;
            for (int i = 0; i < columns; i++)
            {
                sum += matrix[row][i];
            }
            results[row] = sum;
            System.out.println("Results for row " + row + " are : " + sum);
            // wait for others
            try
            {
                barrier.await();
            } catch (InterruptedException ex)
            {
                ex.printStackTrace();
            } catch (BrokenBarrierException ex)
            {
                ex.printStackTrace();
            }
           
           
        }
    }

    public static void main(String args[])
    {
        final int rows = matrix.length;
        results = new int[rows];
        Runnable merger = new Runnable()
        {
            public void run()
            {
                int sum = 0;
                for (int i = 0; i < rows; i++)
                {
                    sum += results[i];
                }
                System.out.println("Results are: " + sum);
            }
        };
        /*
         * public CyclicBarrier(int parties,Runnable barrierAction)
         * Creates a new CyclicBarrier that will trip when the given number
         * of parties (threads) are waiting upon it, and which will execute
         * the merger task when the barrier is tripped, performed
         * by the last thread entering the barrier.
         */
        CyclicBarrier barrier = new CyclicBarrier(rows, merger);
        for (int i = 0; i < rows; i++)
        {
            new Summer(barrier, i).start();
        }
        System.out.println("Waiting...");
    }
}


output :

Results for row 0 are : 1
Waiting...
Results for row 2 are : 9
Results for row 4 are : 25
Results for row 3 are : 16
Results for row 1 are : 4
Results are: 55

To access the source code:
https://bitbucket.org/nkancharla/javaexamples/src/bf0dcc13573e0782807788b99e934b64f592dd41/Barrier?at=master

Tuesday, September 6, 2011

Creating java objects without calling constructors

If the object is serializable, then it is created magically without having the constructor called. This means if a class implements Serializable interface then that class constructor wont be called while Deserialization process.

See below example for more details.


public class parent {
  public parent() {
    System.out.println("parent constructor called");

  }
}



import java.io.Serializable;

public class child extends parent implements Serializable {
   public child() {
      System.out.println("child constructor called");
   }
}



import java.io.*;
public class DeserializeTest {
  public static void main(String[] args) throws IOException, ClassNotFoundException {
    child ms = new child();

    // writing object to byte[]
    System.out.println("writing ms");
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    ObjectOutputStream oos = new ObjectOutputStream(baos);
    oos.writeObject(ms);
    oos.close();
    byte[] objectInBinaryForm = baos.toByteArray();


    // reading object from byte[]
    System.out.println("....Deserialization flow");
    System.out.println("reading ms2");
    ObjectInputStream ois = new ObjectInputStream( new ByteArrayInputStream(objectInBinaryForm) );
    child ms2 = (child) ois.readObject();
    System.out.println("ms == ms2 = " + (ms == ms2));
    System.out.println("ms = " + ms);
    System.out.println("ms2 = " + ms2);
  }
}


The output is the following, note the number of times that each constructor is called:


parent constructor called
child constructor called
writing ms
....Deserialization flow
reading ms2
parent constructor called
ms == ms2 = false
ms = mySerialization.child@1a626f
ms2 = mySerialization.child@95fd19

While deserialization child constructor is not called. but still we got object after deserialzation.

Can you guess how it is done?

Below code will explain you in detail.

For example, to simulate what happens in the DeserializeTest, we could call it with
      SilentObjectCreator.create(child.class, parent.class)
    
Here is my SilentObjectCreator, used to instantiate objects without invoking any constructors:


import sun.reflect.ReflectionFactory;
import java.lang.reflect.Constructor;

public class SilentObjectCreator {

  public static <T> T create(Class<T> clazz) {
    return create(clazz, Object.class);
  }


  public static <T> T create(Class<T> clazz,
                             Class<? super T> parent) {
    try {
      ReflectionFactory rf =  ReflectionFactory.getReflectionFactory();
      Constructor objDef = parent.getDeclaredConstructor();
      Constructor intConstr = rf.newConstructorForSerialization( clazz, objDef );
      return clazz.cast(intConstr.newInstance());
    } catch (RuntimeException e) {
      throw e;
    } catch (Exception e) {
      throw new IllegalStateException("Cannot create object", e);
    }
  }
}



Lets test with our test class below


public class Creatiopublic class CreationTest {
   public static void main(String[] args) {
     // Creating child by calling parent no-args constructor, but not the child constructor.
    System.out.println("Creating child by calling parent no-args constructor, but not the child constructor");
    child ms = SilentObjectCreator.create( child.class, parent.class);
     System.out.println("ms = " + ms);

     // Creating child by not calling any constructors.
     System.out.println("Creating child by not calling any constructors");
     child ms2 = SilentObjectCreator.create( child.class );
     System.out.println("ms2 = " + ms2);
   }
}


In the output we see that in the first case, the NotSerializable constructor is called, but not in the second:

Creating child by calling parent no-args constructor, but not the child constructor
parent constructor called
ms = mySerialization.child@f9f9d8
Creating child by not calling any constructors
ms2 = mySerialization.child@112f614

We can use this mechanism to create just about any class, except abstract classes.