Q51. What is the solution of Thread starvation?

Ans: Fairness is the solution for Starvation. To implement this we should use Lock objects provided by Java and locks only critical section of the code rather than entire method. You have to write code properly so it can never arrives a starvation situation.

Q52. What is a slipped condition?

Ans: Lets assume we have two threads ThreadA and ThreadB. Now both thread progress depends on a signal (boolean flag named goAhead). ThreadA checks the value of goAhead flag ant it is true. So it go ahead but not started yet. Now, ThreadB change the value of goAhead flag to false. A thread can only return from the wait() method if it reacquires the lock on the object it's waiting on.

The current thread must own this object's monitor. The thread releases ownership of this monitor and waits until another thread notifies threads waiting on this object's monitor to wake up either through a call to the notify method or the notifyAll method. The thread then waits until it can re-obtain ownership of the monitor and resumes execution.

Slipped condition can be avoided using properly placing thread synchronization.

Q53. What is the meaning of Lock Reentrance?

Ans: By default we are using re-entrant lock when we use synchronization block in Java. It means same thread has taken the lock and calling another synchronized method from a synchronized method. It is allowed. See below code example.

public class HadoopExam{

   public synchronized first(){

    second();

  }

  public synchronized second(){

    System.out.println("Its allowed");

  }

}

Q54. When you are using Lock object, what is the best place in a method to call unlock() method?

Ans: It is possible your code can throw an exception. And thread does not release a lock, because it cannot reach the code segment which does unlocking. Hence, it is always suggested to put unlock call in finally block of the method.

Q55. What problem is solved by read/write lock?

Ans: When there is a shared resource and many threads are reading them at the same time then there is no problem. We can use normal lock class. But what happen, when we want multiple threads reading and few threads are also updating the shared resource. In this case shared resource must be updated by single thread at a time. And while writing is going on than further reading and writing should be allowed. Such type of scenario can be handled using read/write lock.

Q56. What is a Counting Semaphore?

Ans : Java provides built in semaphore (which you can imagine a locked counter). A counting semaphore. Conceptually, a semaphore maintains a set of permits. Each acquire() blocks if necessary until a permit is available, and then takes it. Each release() adds a permit, potentially releasing a blocking acquirer. However, no actual permit objects are used; the Semaphore just keeps a count of the number available and acts accordingly.

Semaphores are often used to restrict the number of threads than can access some (physical or logical) resource.

Q57. What is a BlcokingQueue?

Ans: Lets assume you have 1000s of tasks (Runnable), you want to process it. And there is a ThreadPool of 10 threads(Consumer threads), which will process each tasks. We have a Queue (Task holder) with defined size of 100. So this queue can hold upto 100 tasks maximum at a time. Now at one end of the Queue you are keep adding the tasks (Runnable) using a Producer thread. And at other end ThreadPool consumer will dequeening tasks and processing the same. Main point here is , when Queue is full (100 tasks in a queue) , producer is blocked and cannot add more tasks to blocking queue. If Queue is empty than consumer thread cannot de-queue any tasks and will block until new tasks is added. Queue which has this behavior is called Blocking Queue.

Premium Training : Spark Full Length Training : with Hands On Lab

Previous Next