Confirmed users
398
edits
NuwaTemplateProcess: Difference between revisions
Jump to navigation
Jump to search
→Mutics and Conditions
(→Binder) |
|||
| Line 25: | Line 25: | ||
== Mutics and Conditions == | == Mutics and Conditions == | ||
For mutics, there always one of threads will own the lock. Nuwa freeze just before pthread_mutex_lock(), it means still not owning the mutex. So, the wrapper needs only to call pthread_mutex_lock() at parasited thread. If the mutex is already owned by another thread, and this thread is blocked by calling pthread_mutex_lock(), not by sThreadFreezeLock, the wrapper also calls pthread_mutex_lock() and be blocked again at the parasited thread. So, the wrapper of pthread_mutex_lock() always redo the lock in parasited threads. | |||
For conditions of pthread, it is more complex since it can depend on a mutex. Once the pthread_cond_wait() is called, it means the given mutex, if have one, is released. The give mutex is acquired again when the call is returned. For parasited thread, we need to acquire the lock before calling pthread_cond_wait() to restore the context. So, it can be one of two situations, the mutex is hold by some one or free/released. pthread_mutex_trylock() can be used to test if a mutex have been acquired. For free/released situation, pthread_mutex_trylock() will acquire the mutex and pthreaad_cond_wait() will put the mutex back to the released state, so it is fine. For hold state, pthread_mutex_trylock() can not acquire the mutex, pthread_cond_wait() will put the mutex to the released state different from original hold state. So, we need to acquire the mutex to put is back to hold state after the parasited thread was blocked by pthread_cond_wait(). So, the wrapper will ask the main thread to acquire the mutex again, then the state of the mutex will keep consistent with Nuwa process. | |||
== Dark Magic of Stack == | == Dark Magic of Stack == | ||