Krishna Kumar S

Thanks Jeff !!! got it.

Thanks Henry, Shivalkar and Jeff. Need few more clarifications.
Consider the same example with little modification,

Class College{ private HashMap student_map = new HashMap(); private HashMap student_metadata_map = new HashMap(); //add student and id public synchronized void add(Student s) { student_map.put(s.getId(), s); student_metadata_map .put(s.getId(),new StudentMetaData(s)); } //remove student and id public synchronized void remove(Student s){ student_map.remove(s.getId()); student_metadata_map.remove(s.getId()); }

In this case , lets consider both student map and student meta data map are atomic and needs to be synchronized.
Would collections.sync'dmap or concurrent hash map be required in this scenario or normal Hashmap is suffice??? (Note: Both maps are updated/accessed only from synchronized method of College class).

Thanks in Advance.

I understand that get and put method of hash map is not thread safe. So if multiple threads access, these methods may get interleaved and may cause hashmap to be corrupted.
so considering the below example, is it good to use hash map synchronized manually as given or is it better to use concurrent hashmap and WHY?

Class College{ private HashMap student_map = new HashMap(); //add student and id public synchronized void add(Student s) { student_map.put(s.getId(), s); } //remove student and id public synchronized void remove(Student s){ student_map.remove(s.getId()); } public synchronized Student get(int id){ return student_map.get(id); } }

What do you mean by until program quits??? if you want to periodically execute some task have a look on " ScheduledExecutorService".

Example:

ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor();
scheduler.scheduleAtFixedRate(runnabletask, initial_delay, periodic_interval, Timeunit);

What do you mean by until program quits??? if you want to periodically execute some task have a look on " ScheduledExecutorService".

Example:

ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor();
scheduler.scheduleAtFixedRate(runnabletask, initial_delay, periodic_interval, Timeunit);

Though i do not get the usage of this program. I could explain the output of your program.
Once notify() is executed in Operator2 , operator 1 will be taken from wait state and placed into "ready to run" state.
But it doesn't guarantee that it get the CPU as soon as it is notified. so there are still chances that Operator2 gets the CPU and get the lock of this(operator2).
If you want both should execute one after the other, both should wait and notify each other.
Hope it helps!!!

What exactly is your problem statement??
The Operator1 extends thread but has not overridden the run method. so why to extend the Thread class.
For inter thread communication objects are used between threads. (to wait/ notify on that object you need to acquire the lock of it).
But why you are waiting on thread t2. Note: Thread wait on shared objects for synchronization.


Example: Stock objects, Stock Analyzer thread , Stock Modifier thread. Stock Analyzer thread wait on Stock object and will get notification when Stock Modifier thread updates it.

Yeah that's why i posted lesson learnt as "Do not let the thread to hold multiple locks and gets into wait state."

Hi Jeff. Thanks and Sorry for the late reply.

As per your statement,
"The real lesson is that when acquiring multiple locks, make sure that all threads acquire those locks in the same order. "
But i could see problem even when following this.

Say There is thread safe model (MVC pattern) which will be accessed by two Threads (T1 and T2). similarly both threads are using object (say obj) for inter thread communication (wait-notifyall).
The order to acquire the lock is defined (first to acquire model then to acquire obj).

Deadlock scenario:

If T1 acquires the model lock and subsequently acquires obj lock. Then T1 wait on obj and holds the lock of model. T1 will come out of waiting state only when T2 notifies it.
T2 cannot notify T1 as to proceed further it need the lock of model. and hence deadlock.

Thanks guys ...

Because of the bad design it was in deadlock. Now got them resolved.

Lesson learnt: Do not let the thread to hold the lock and gets into wait state.

Hi All,
Suppose say , if a Scheduled Executor is executing a periodic runnable task every 1 minute. and if the executing thread gets in to sleep/waiting state for 5 mins.
Will the subsequent call every 1 minute be in call stack???


Thanks a lot
Krishna

Class XXX{
boolean readyToRead = false;
public synchronized void demo(){
//do some initialization
synchronized(obj){
if(readyToRead){
obj.wait()
}

if(some other condition){
readyToRead = true;
obj.notifyAll();
}
}
}
}


the problem is when the code waits it wait with the instance lock of the class XXX. so some other thread which has to notify the waiting thread need this lock to proceed further. so i'm suspecting deadlock. could anyone suggest me how i should avoid deadlock in inter thread communication? Thanks a lot.