Understanding Monitor in Dalvik

380 views

Published on

This slides is about SMP internals for Dalvik.Monitor is a synchronization construct that allows threads to have both mutux and the ability to wait for a certain condition to become true in Dalvik.

The latest source code of demos could be got from https://github.com/tek-life/Understanding_Monitor_for_Dalvik.

If there is something inappropriate in slides or demos, please let me know.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
380
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Understanding Monitor in Dalvik

  1. 1. Mutex & Cooperation in Dalvik Understanding Monitor Haifeng Li 2014-1-6
  2. 2. Outline • Background • How To: Implement in Dalvik • Optimization: Thin Lock & Fat Lock 2
  3. 3. Why Need Mutex? • A snippets about Xiao ming 3
  4. 4. Why Need Cooperation • A snippets about writer & reader 4
  5. 5. The Graphical Depiction of Monitor Owner Entry 1 Enter Wait release acquire 3 2 5 Acquire 4 Release & exit A Waiting Thread An Active Thread ∙ The picture is from inside the java machine, Figure 20-1. 5
  6. 6. How to Implement them? • Mutex -- Synchronized • Cooperation -- wait() & notify() 6
  7. 7. Key Structure struct Monitor { Thread* owner; int lockCount; Object* obj; Thread* /* which thread currently owns the lock? */ /* owner's recursive lock depth */ /* what object are we part of [debug only] */ waitSet; /* threads currently waiting on this monitor */ pthread_mutex_t lock; Monitor* next; … }; 7
  8. 8. Locking Algorithm (1) • Lock Monitor without Contention Thread A will lock a unlocked object – Call pthread_mutex_lock to Lock monitor->lock – Set monitor->owner = Thread A 8
  9. 9. Locking Algorithm (2) • Locking with Contention Thread B tries to acquire a lock held by thread A. • B ’s check that B owns the lock will fail • B call pthread_mutex_lock() to acquire monitor->lock. If fail, B sleep on monitor->lock. 9
  10. 10. Cooperation Algorithm (1) • Thread A grasp the monitor and will wait. – – – – – – – – Append self to monitor->waitSet Store monitor->lockcount Clear monitor->owner Update thread status to THREAD_WAIT Call pthread_mutex_lock to lock thread->waitmutex Set thread->waitMonitor = monitor Call pthread_mutex_unlock to unlock the monitor Call pthread_cond_wait to be scheduled. P.S.: pthread_cond_wait will call pthread_mutex_unlock 10
  11. 11. Cooperation Algorithm (2) • Thread B grasp the monitor and notify a thread. – Thread B traverse monitor->waitSet, if there is a thread, call pthread_cond_signal to wakeup. 11
  12. 12. Cooperation Algorithm (3) • Thread A was notified by one Thread. – Pthread_mutex_lock thread->waitMutex – Clear thread->waitMonitor – Pthread_mutex_unlock thread->waitMutex – Reacquire the monitor – Set monitor->owner – Restore monitor->lockCount – Update thread status to THREAD_RUNNING 12
  13. 13. Optimization: Thin Lock & Fat Lock • Every object should maintenance a monitor. The monitor occupy object->lock and itself. • But someone found that median of 80% of all lock operations are on unlocked objects, or nesting is very shallow. – Locking an unlocked object – Locking an object already locked by current thread a small number of times (shallow nested locking) – Locking an object already locked by the current thread many times (deeply nested locking) 13
  14. 14. • Result is from paper, David F.Bacon etc., Thin locks: feather weight Synchronization for Java. 14
  15. 15. Thin Lock • Thin lock reuse object->lock, and the layout is as follows. 31 19 Count 3 Thread id 0 Hash state 0 – Count: Nested lock count – Thread id: is a identifier. Not System thread id. – LSB: 0 indicates thin lock. 15
  16. 16. Fat Lock • Object->lock layout is as below. 31 3 Monitor Pointer 0 Hash state 1 Monitor – LSB: 1 indicates fat lock. 16
  17. 17. Locking Algorithm (1) • Locking without Contention – Initially - lock field is 0, thread A wishes to lock. – If succeeds, object won’t be locked by another thread and we now own lock 17
  18. 18. Locking Algorithm (2) • Locking with Contention(Lock is thin) Thread B tries to acquire a lock held by thread A. – B ’s check that B owns the lock will fail – B needs to force a transition from thin to fat • B enters a spin-locking loop • Once A unlocks, B will obtain • B creates a fat lock, assigns object->lock to new monitor • B changes object->lock to 1 18
  19. 19. Locking Algorithm (3) • Locking with Contention(Lock is fat) Thread B tries to acquire a lock held by thread A. • B ’s check that B owns the lock will fail • B call pthread_mutex_lock() to acquire monitor->lock. If fail, B sleep on monitor->lock. 19
  20. 20. Cooperation Algorithm • Thread A grasp the thin lock and will wait. – Fatten the lock firstly –… 20

×