Problems encountered in the project, involving the main thread and child threads of communication and synchronization issues, the test found deadlock situation, record
void Main () {
threadb threadb = new threadb ();
threadb. Start ();
synchronized (handler) {
try {
log.e ("Sync_threadmanager", "Hold_handeler");
handler.wait ();
log.e ("Sync_threadmanager", "Wait_ Handeler ");
} catch (Interruptedexception e) {
//TODO auto-generated catch block
e.printstacktrace ();
}
}
}
THREADB extends Thread
{
public void Run () {
Looper.prepare ();
Bhandler = new Handler () {
@Override
public void Handlemessage (msg) {
Do something here
}
};
Synchronized (handler) {
Handler.notify ();
}
Looper.loop ();
}
}
The above code design intent is: When the red code executes, starts another thread, the main thread executes first to the blue part (wait), at this time, the suspend function causes the main thread to be in the state, and releases the hold synchronization object lock handler. After that, the child thread threadb gets the sync lock handler,threadb initialized, calls the Notify method to notify the thread that called wait, and then the main thread requests the sync lock again, and if it succeeds, executes the code after wait. This process ensures that the bhandler of the child thread threadb is successfully initialized, and that main thread main can communicate through Bhandler and child threads later. In most cases, the program runs normally. But in the case of multithreading does not guarantee this order, may appear suspended animation.
The normal situation is as follows:
1.Main execution to synchronized (handler), preemptive handler lock object
2.VM switch Execution threadb, execute to synchronized (handler) found handler lock object has been hold by main process, at this time threadb blocking wait
3.Main continue to execute hanlder.wait (), release handler lock and wait
4.THREADB Get handler lock, initialize Bhandler, execute hanlder.notify ()
5.Main was notified, re-request handler lock, but at this time threadb not out of sync code area, no release handler lock, main continue to wait, threadb continue to execute, release Hanlder
6.Main Request Hanlder Lock succeeded, continue after wait action
THREADB First Execute:
1.Main Executive Threadb.start ()
2.VM switch to execute threadb and get handler lock.
3.VM switch execution Main, found Hanlder lock is Threadb hold, blocking wait
4.VM Switch THREADB, continue to execute notify until out of sync code area, release Hanlder lock
5.VM switch execution Main, get Hanlder lock, execute to wait, block waiting for other threads notify
6. In this example, notify only executed once, so main, no longer waiting for another thread to call it a meal (notify), had to starve
The main problem is that notify cannot be notified to the incoming wait thread, so the workaround is to make sure that main line enters upgradeable into the synchronized, to determine if main has entered synchronized before THREADB executes synchronized