Wednesday, July 29, 2015

Difference Between Semaphore and Mutex and How to create a custom semaphore

  We know  that if we want guard a critical section(shared resource),so that a single thread can access it,
we use synchronize block for the critical section.So that in a multi threaded environment we will not face any lost update problem.There are number  of ways to make a shared resource thread safe.Like we all know one of them is by using synchronize keyword.In java ,there are some constructs and tools to help the developer to achieve this goal..Example of some such constructs are Semaphore,CountDownLatch,CyclicBarrier,Concurrent HashMap,HashTable,wait,notify,notifyAll.By using all the tools and constructs we can achieve our goal,ie to guard a shared resource(critical section) in a multi threaded environment.From now Onwards we will call such constructs as synchronizes. 

Mutex(One Thread at a Time):

Assume the scenario that there is a small library having only chair to sit and read.But there are N number of students are waiting in queue.So the first student will come and take the key and enters the room.Till then all other students are waiting.When he will complete he will  come out and  give the key to the next student in the queue.Then only the next student will enter the room and will start the study.Here the study room is the critical resource.And all the students are threads.They are accessing the critical section one by one,in sequential manner.
Here mutex is the perfect candidate to apply. Because here mutually exclusion is desired.
A mutex is locking mechanism used to synchronize access to a resource. Only one task (can be a thread or process) can acquire the mutex. It means there is ownership associated with mutex, and only the owner can release the lock (mutex).Here in our example student is the owner of the resource(library room) and after the completion of the study,he will release the room(the shared resource).
 A mutex(lock) has the concept of ownership so it may be reentrant. That means that a thread that holds a lock, is allowed to call a critical section again where same lock is required. Because the thread already holds the lock and is allowed to reenter it.

Semaphores(Number Of Specified threads at a time):

As we saw in mutex only one thread can access the critical section at a time.But In contrary to this more than one thread can access the critical section at the same time.Let's come to our previous example.Assume we have a large library room having capacity for 100 students.There are 100 chairs and and 100 students can read at the same time togeather.Assume here that the room is the critical section, and students are threads.Initially we define the semaphore count as hundred.When one student will go inside he will increase the permit(say total number of working threads) by one.Similarly when second student will go inside,  he will increase the permit by one.And so on.Before giving permission to a student to enter the room , the total number of permit will be checked.If it is less than 100 ,then only the particular student will be allowed to go inside.Otherwise he will wait till some student to come and decrease the permit by one.

In Java , Semaphores have no notion of ownership, so they cannot be reentrant.One property of Semaphores in Java is that release doesn’t have to be called by the same thread as acquire.In a scenario assume we have a code that creating threads in a pool if and only if semaphore.acquire() succeed.Now after this those threads will start and call semaphore.release() when they complete.This is a useful property that we don’t have with mutexes(lock) in Java.A thread can succeeded in semaphore.acquire(), if there is at least one permit is available.

Now let's try to understand semaphore with the help of an example.The below example is a modified version of the example of semaphore as given in java doc.


class Pool {
   private static final int MAX_AVAILABLE = 10;
       private final Semaphore available = new Semaphore(MAX_AVAILABLE, true);
       public Object getItem() throws InterruptedException {
           System.out.println("Going to  acquire lock for thread id "+Thread.currentThread().getId()+" available permit "+available.availablePermits() +" ");
         available.acquire();
       
       //  System.out.println("lock acquired for thread id "+Thread.currentThread().getId()+" available permit "+available.availablePermits() +" ");
         return getNextAvailableItem();
       }
       public void putItem(Object x) {
         if (markAsUnused(x))
           available.release();
         System.out.println("lock released for thread id "+Thread.currentThread().getId());
       }
       // Not a particularly efficient data structure; just for demo
       protected String[] items ={"a","b","c","d","e","f","g","h","i","j"};
       protected boolean[] used = new boolean[MAX_AVAILABLE];
       protected synchronized Object getNextAvailableItem() {
         for (int i = 0; i < MAX_AVAILABLE; ++i) {
           if (!used[i]) {
              used[i] = true;
              return items[i];
           }
         }
         return null; // not reached
       }
       protected synchronized boolean markAsUnused(Object item) {
         for (int i = 0; i < MAX_AVAILABLE; ++i) {
           if (item == items[i]) {
              if (used[i]) {
                used[i] = false;
                return true;
              } else
                return false;
           }
         }
         return false;
       }
     }
}



public class PoolTest {
    public static void main(String[] args) throws InterruptedException {
           Pool t1=new Pool();
for(int i=0;i<200 i="" p="">
new Thread(                 new Runnable(){                     public void run(){                         try {                             Thread.currentThread().setName(new Object().toString());                             System.out.println(t1.getItem().toString()+" for thread id "+Thread.currentThread().getId());                         } catch (InterruptedException e) {                             // TODO Auto-generated catch block                             e.printStackTrace();                         }                                             t1.putItem("a");                                         }             }).start();         }             } }

Explanation:

Just look at the code above.Here initially we define a semaphore with permit 10.In getItem() method first thread will call acquire() method.It is a blocking call.It acquires a permit from this semaphore and blocks until one permit is available or thread interruption occurs.If one permit is available ,then the the acquire() method return immediately by reducing the number of available permits by one.
If no permit is available then the current thread becomes disabled for thread scheduling purposes and lies idle until one of two things happens:
Some other thread invokes the release() method on the same  semaphore and the current thread is next to be assigned a permit; or
Some other thread interrupts the current thread. And then we call the method getNextAvailableItem().It returns an item from the items array defined in pool class.

The thread call the putItem(Object x) method.This method takes the item and mark it as unused.Then call the realease method on the semaphore.
Releases a permit, increasing the number of available permits by one. If any threads are trying to acquire a permit, then one is selected and given the permit that was just released. That thread is (re)enabled for thread scheduling purposes.
There is no requirement that a thread that releases a permit must have acquired that permit by calling acquire() method.

 Wrong Uses Of Semaphore:

But note one thing here that, we are always returning the string "a" in putItem(Object x) method.But we taking every item from the array.so there will be a case where all the items a,b,c,d,e,f,g,h,i,j will be consumed from the array but only a will be retuned.so,in that case number of permits will be 1 only.Here this is a case where permits are taken but never returned.That is only acquire occurs but no release.This is a misuse of semaphore.

Also one more thing to note here that we should alway call release() method in finally block.If some exception occurs before calling the release method,then also release can be called safely.And number of permit can be increased.

Fairness In Semaphore:

Java's built-in concurrency tools (synchronized, wait(), notify()) do not mention which thread should be get turn for getting the access to the critical section when a lock is released. It is up to the implementation of the JVM to decide..
Fairness gives us more control: when the lock is released, the thread with the longest wait time is given the lock (FIFO processing). Without fairness we might have a situation where a thread is always waiting for the lock because  other threads  are continuously requesting for the same.

 Semaphores can be initialized with constructor Semaphore(int permits) or Semaphore(int permits,boolean fair).Semaphore(int permits,boolean fair) creates a semaphore with fairness setting.When fair is set to true,the semaphore gives permit to access the critical section in the order the threads have ask for it (FIFO).And when fair is set as false,then semaphore can grant access to the the thread asking for it rather than the thread which is waiting before.To avoid starving fair should be set to true.

How TO Break Fairness Policy:

There is a method with signature public boolen tryAcquire().This method acquires a permit from this semaphore,only if one is available at the time of invocation. This method Acquires a permit, if one is available and returns immediately, with the value true, reducing the number of available permits by one.If no permit is available, then the method will return immediately with value false. Even when this semaphore has been set to use a fair ordering policy, a call to tryAcquire() will immediately acquire a permit if one is available, whether or not other threads are currently waiting. This (rude) "barging" behavior can be useful in certain circumstances, even though it breaks fairness.  If we want to respect the fairness setting that we set in constructor, then we should use tryAcquire(0, TimeUnit.SECONDS)


Acquire and Release multiple permits at same time:

There is a  method with signature  public boolean tryAcquire(int permits).When the method is called, acquires the given number of permits, if they are available, and returns immediately, with the value true, reducing the number of available permits by the given amount.
If insufficient permits are available then this method will return immediately with the value false and the number of available permits is unchanged.

Similarly we can release more than one permit in one go with the help of below method

public void release(int permits)

Releases the given number of permits, increasing the number of available permits by that amount. If any threads are trying to acquire permits, then one is selected and given the permits that were just released. If the number of available permits satisfies that thread's request then that thread is (re)enabled for thread scheduling purposes; otherwise the thread will wait until sufficient permits are available. If there are still permits available after this thread's request has been satisfied, then those permits are assigned in turn to other threads trying to acquire permits.There is no requirement that a thread that releases a permit must have acquired that permit. 

Create a custom Semaphore:

Finally, let's take a look how to create a custom semaphore with minimal setting.
public class MySemaphore {
        private int permit;

        public MySemaphore () {
            this(0);
        }

        public MySemaphore (int i) {
            if (i < 0)
                throw new IllegalArgumentException(i + " < 0");
            counter = i;
        }

        public synchronized void release() {
            
                this.notify();
            
            permit++;
        }

        public synchronized void acquire() throws InterruptedException {
            while (permit== 0) {
                this.wait();
            }
            permit--;
        }
    }


Monday, July 20, 2015

Multi hop tunneling in Android/Java

Once I  was mentoring an intern for an app development in Android. The aim of the application was to create an android app for an existing web application.But the application is deployed in a server which is not in public domain.The application is in LAN.But the aim of the android app was to monitor the application on the go.Even if the support guy is not in  the office,but still he should be able to access the app in his mobile device.

Assume the scenarios are like this.Suppose server A is the gateway of the LAN.And server B is the central server in the LAN which is accessible from the server A.And C is another central server which is accessible from server B. And our web application is deployed in server D in the same LAN which is accessible from server C.Our web application is deployed in tomcat installed in server D.And tomcat is running on port 9091.Our aim is to access the URL eg. http://ipaddress:9091/appname  in our android application. 

Immediately some solutions come to mind.One of them is first open the gateway of the office LAN with the help of putty software.Then forward the central server of the LAN by ssh tunneling which is accessible from the LAN gateway . Then open the desired server from  the Central server.For this we can take the help of putty software for android.Or we can use ConnectBot for android.Then we will do all the required tunneling for all the servers.But here one disadvantage is  we have to install one more extra application like putty or ConnectBot in the mobile device.So here comes a  third party dependence,which is not desired. So what can be done here?

So next thing we want to do is multi hop ssh tunneling with the help of some third party api which can be imported  as a library with the application. The available APIs are Chilkat SSH,JSCH,Trilead SSH etc.
But we decided to use JSCH(Java secure channel).
Now we will  do multiple hop ssh tunneling by using JSCH.And we will look implementation  of port forwarding by JSCH.




import com.jcraft.jsch.Channel;
import com.jcraft.jsch.JSch;
import com.jcraft.jsch.Session;

public class PortForward {
    public static void main(String[] args) {
     
 
        int lport;
        String rhost;
        int rport;
      //  protected String doInBackground(String... arg0) {
            JSch jsch=new JSch();
            try{
                String user="LanGateway";
                String host="LanGatewayIp";
                String pswd="LanGatewayPassword";
                Session session=jsch.getSession(user, host, 22);
                session.setPassword(pswd);
                java.util.Properties config = new java.util.Properties();
                config.put("StrictHostKeyChecking", "no");
                session.setConfig(config);
                session.connect();

                lport=2249;
                rhost= "CentralServerIp";
                rport= 22;
                int assinged_port=session.setPortForwardingL(lport, rhost, rport);
           
                String user2="UserForCentralServer";
                String pswd2= "CentralServerPassword";
                Session session2=jsch.getSession(user2, "localhost", assinged_port);
                session2.setPassword(pswd2);

                session2.setConfig(config);

                session2.connect();
                lport=2248;
                rhost= "CentralServer2";
                rport= 22;
                int assinged_port2=session2.setPortForwardingL(lport, rhost, rport);
            
                String user3="UserForCentralServer2";
                String pswd3= "PasswordForCentralServer2";
                Session session3=jsch.getSession(user3, "localhost", assinged_port2);
                session3.setPassword(pswd3);

                session3.setConfig(config);
                session3.connect();
                lport=2246;
                rhost= "webApplicationServer";
                rport= 22;
                int assinged_port3=session3.setPortForwardingL(lport, rhost, rport);
       

                String user4="webapplicationServerUserName";
                String pswd4= "webapplicationServerPassword";
                Session session4=jsch.getSession(user4,           "localhost", assinged_port3);
                session4.setPassword(pswd4);
                session4.setConfig(config);
                session4.connect();

                lport=9095;
                rhost= "localhost";
                rport= 9091;
               int  assinged_port4=session4.setPortForwardingL(lport, rhost, rport);

 /*
  You can  write code here to check if the port for tomcat is forwarded properly or not.Just write code to hit the url http://localhost:9095.And you will get the tomcat's home page as     response.Otherwise just open your browser and write http://localhost:9095 in address bar and hit enter  button.You will see tomcat's home page in your browser.
 */
              
 }
     catch(Exception e){
       e.printStacktrace();

  }


           // return rhost;
}}

The above code is straight forward and self explanatory.In similar manner we can forward any port locally.
Like we can forward Mysql port  also to access Mysql of the remote system in our machine.


Saturday, July 4, 2015

Use of ThreadLocal

In this article we will discuss about uses and misuses of  ThreadLocal.What is ThreadLocal?Why it is introduced in java?Are there any competitors of  ThreadLocal?

As the name suggests , it will help a thread to keep some object as it's local. The value stored in a ThreadLocal instance is local to the current running thread and any other method running on the same thread will see the same value.Some people argue that synchronization is  a competitor of ThreadLocal.
But both have different use-case.

Use Case Of  Synchronization:

Synchronizing a method or block is useful when multiple threads access the shared variable  used in a method.But we don't want lost update problem or race condition here.For example we have a method which is updating an account balance and that account is a shared one.That is used by more than one share holder.For this Synchronization is a must.Here we want the account is to be updated but not at the same instant of time.If more than one share holder is accessing the account at same time they should  come one by one.And the updated value of one transaction should be clearly visible to the next share holder.If we let them all to do the transaction at the same instant of time, lost update problem will arise.Here Synchronization is the strong candidate to be in use.

Use Case Of  ThreadLocal:

1.ThreadLocal is useful to make per thread context value unique.Like if a thread want it's own transaction id,it's own security context,it's own database connection.

2.We can use TheadLocal as a wrapper on any non Threadsafe class to make it Threadsafe.

3.If we want to pass any information from one method to another , without passing it as method argument ,on which the same thread is executing , then ThreadLocal is the suitable candidate for it.

 Implementation Of  ThreadLocal:

Consider we have a scenario where we have a single task which is executed in a multithreaded environment.Suppose we have two threads  and both are performing the same task simultaneously.But it is instructed to first thread to perform  the task 10 times and to the second thread to perform the task 20 times.How can we do this by using ThreadLocal.


1.By Overriding
initialValue method


public class ThreadLocaleExample1 {
    public void startTheTask(){
      
        final ThreadLocal threadsOwnLocalCopy = new ThreadLocal(){
             @Override
                protected Integer initialValue()
                {
                    return new Integer(0);
                }
        };
        Thread t1 = new Thread() {
          public void run() {
      
         while ((Integer)threadsOwnLocalCopy.get()<new Integer(10))  {                doTheTask();
              Integer previousCount = (Integer) threadsOwnLocalCopy.get();
              threadsOwnLocalCopy.set(new Integer(previousCount.intValue() + 1));
            }
            System.out.println((Integer)threadsOwnLocalCopy.get());
          }
        };
        Thread t2 = new Thread() {
       public void run() {

  while ((Integer)threadsOwnLocalCopy.get()<new Integer(20)) 
                  { doTheTask();           
   Integer previousCount = (Integer) threadsOwnLocalCopy.get();
              threadsOwnLocalCopy.set(new Integer(previousCount.intValue() + 1));
            }
              System.out.println((Integer)threadsOwnLocalCopy.get());
          }
        };
        t1.start();
        t2.start();
        }
    public void doTheTask(){
        System.out.println("Do some meaningful task here which is required repetitively");
    }
        public static void main(String[] args) {
            ThreadLocaleExample1 threadLocaleExample1=new ThreadLocaleExample1();
            threadLocaleExample1.startTheTask();
        }
}

Here each thread is given a counter to maintain the number of time the task is executed.
Here we take a ThreadLocal and override the initialValue method and return a new Integer with initial value 0.When threadsOwnLocalCopy.get() is called for first time by each thread,the initialValue method is invoked and a new Integer value is returned.


2.By Implementing setter Method:

public class ThreadLocaleExample2 {
    public void startcall(){
    final ThreadLocal<Integer> threadsOwnLocalCopy = new ThreadLocal<Integer>();
    Thread t1 = new Thread() {
      public void run() {
       
          threadsOwnLocalCopy.set(new Integer(0));
        while ((Integer)threadsOwnLocalCopy.get()<new Integer(10)) {
          Integer prevCount = (Integer) threadsOwnLocalCopy.get();
          threadsOwnLocalCopy.set(new Integer(prevCount.intValue() + 1));
        }
        System.out.println((Integer)threadsOwnLocalCopy.get());
      }
    };
    Thread t2 = new Thread() {
      public void run() {
          threadsOwnLocalCopy.set(new Integer(0));
       while ((Integer)threadsOwnLocalCopy.get()<new Integer(20)) {
          Integer prevCount = (Integer) threadsOwnLocalCopy.get();
          threadsOwnLocalCopy.set(new Integer(prevCount.intValue() + 1));
        }
      }
    };
    t1.start();
    t2.start();
    }
    public void doTheTask(){
        System.out.println("Do some meaningful task here which is required repetitively");
    }
    public static void main(String[] args) {
        ThreadLocaleExample2 threadLocaleExample=new ThreadLocaleExample2();
        threadLocaleExample.startcall();
    }
}

In the second approach , we have not overridden the intialValue() method , but here we are using set() method of ThreadLocal to set the local value of the thread in the very first line of the thread execution.
And then we are getting it and incrementing it  as usual.

Internal Implementation of ThreadLocal (Open up the Bonnet and see what is inside the cover):
 
Now let's discuss internal implementation of ThreadLocal. If we open the thread class we will see

/* ThreadLocal values pertaining to this thread. This map is maintain  by the ThreadLocal class. */
    ThreadLocal.ThreadLocalMap threadLocals = null;

So Thread class  contains a reference of ThreadLocal.But ThreadLocal class contains ThreadLocaMap as a field.ThreadLocalMap is a customized hash map suitable only fo maintaining thread local values.The
ThreadLocaMap class is static  inner class of ThreadLocal.so we can say ThreadLocal is the main class and ThreadLocaMap is a subclass.

The entries in this hash map(ThreadLocaMap ) extend WeakReference,using the main ref field (that is ThreadLocal object) as the key.when a set or get is called on a ThreadLocal it first find the current thread.Then get the map (ThreadLocalMap)  associated with the current thread.it get the map by calling a method of ThreadLocal class and passing the current thread as parameter.The method defination is as  follows

ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
    }


 And use this ThreadLocal as the key to find the value from the obtained map.The method used for this  is from ThreadLocalMap class.The method signature as follows

  private Entry getEntry(ThreadLocal key) ;

 This method return the value that is set by using setter method or  initialValue() method as discussed in above paragraph.

Misuse  of ThreadLocal:
 There are various uses of ThreadLocal but in  absence  of  a little care we can face a lot of disaster.
Follow the below code 


public class ThreadLocalExample3 {
        private static ThreadLocal threadsOwnLocalCopy = new ThreadLocal();
        static {
            threadsOwnLocalCopy.set(5);
        }
        public int getCountOfThread() {
        return threadsOwnLocalCopy.get();
        }
   
        }



Here in above code we have used a ThreadLocal and we initialized  ThreadLocal in a static block. 
But the above implementation is not correct Since the above static initialization block will execute only once when the first thread references the class ThreadLocalExample3.When the second thread will come in, it will not execute ThreadLocalExample3.set(5) on that thread, therefore ThreadLocalExample3.get()  will returns null instead of 0.
 
 

Purging of ThreadLocal Object: 

Now the question is when the ThreadLocal object will get purged(Garbage Collected)?The main issue is that of memory usage.When we initialize an object through the initialValue() method, it’s easy to forget that we have created it.If that object in turn will create some more object, they all will be available through the life time of the thread.But assuming that the thread is a long running process , then there is a chance that all the objects associated with that thread will be garbage collected only when the thread will die(with some exception) or finish smoothly.Let's consider some cases of it.

1.Thread Pooling
Just assume we have a Thread pool implementation like below.

ExecutorService service = Executors.newFixedThreadPool(10);
service.execute(new RunnableInstance());


So that our threads will be recycled and will not finish.As it is an encouraging design pattern, most of the real life implementation use Thread pool.In this case the associated ThreadLocal Objects will always be available in memory space whether the thread is in use or not.And this will create memory leak issue .

2.Sevlet Container 

One  more example for this is Application container which uses Thread Pooling to serve the requests.The thread that serve the servlet request will stay alive in the container till the time the server is not shut down.So all the ThreadLocal referenced object will  be available in the container till the container is shut down.

Steps to avoid this:
In the  completion of the process never forget to call the ThreadLocal.remove() method.This way when we call ThreadLocal.get() again in the same thread after sometime, the initialValue() method will automatically be called, and the new instance will be created.It also make sense when we use setter of ThreadLocal to initialize a value.So as a rule of thumb, always reset or clean  the  ThreadLocal  after finished with the unit of task, even though it is used in a pooled environment or not.