1 / 11

The Road to Responsiveness in Eclipse 3.0

The Road to Responsiveness in Eclipse 3.0. John Arthorne, Eclipse Platform Core Team. The road to responsiveness. Step 0 - If you make no changes, you will be ok (even slightly better) Step 1 - Revisit locks to reduce contention with background jobs

gerda
Télécharger la présentation

The Road to Responsiveness in Eclipse 3.0

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Road to Responsiveness in Eclipse 3.0 John Arthorne, Eclipse Platform Core Team

  2. The road to responsiveness • Step 0 - If you make no changes, you will be ok (even slightly better) • Step 1 - Revisit locks to reduce contention with background jobs • Step 2 – Move long read only operations to background • Step 3 – Move long writing operations to background

  3. Step 0 – what if I do nothing? • Backwards compatibility: no worse than Eclipse 2.1 • Blockage will always be reported to the user • The UI is kept alive (painting) at all costs • Cancelation is now always possible (even during deadlock) • Lack of responsiveness in one component can kill responsiveness gains in other components

  4. Step 1 - Revisit locks to reduce contention • ISchedulingRule: generic hierarchical locks • A given scheduling rule can only be “owned” by one thread at a time • No two threads can own rules that conflict with each other • Implemented by clients – every plug-in can define their own rules • Rules can be nested to form rule hierarchies • ILock: re-entrant lock, like Java object monitors, except: • Aware of syncExec: carries over to UI thread • Deadlock reporting and recovery

  5. Step 1 – Reducing contention (continued) • IWorkspace.run was used for both batching and locking • This has been decoupled: new IWorkspace.run with scheduling rule, WorkspaceJob subclass to obtain batching inside a job • Can now use scheduling rules to lock selected resources • IResource implements ISchedulingRule

  6. Step 2 – Move read-only operations to background • Less risk in moving read-only operations into background • Can be done with little or no contention • Watch for assumptions about UI thread and thread safety • Examples: searching, indexing, decoration, repository view • We have been doing this all along, but difficulties arise • Hard to coordinate access to resources, CPU • Background processes that don’t know about each other are prone to deadlock

  7. Step 2 – Moving to the background (continued) • Job API: org.eclipse.core.runtime.jobs • Job: a unit of work scheduled to run asynchronously • Why not just java.lang.Thread? • Lighter weight: uses a shared thread pool • Support for progress feedback and cancellation • Priorities and scheduling rules • Richer scheduling: run now, run later, run repeatedly • Job listeners can find out when jobs start, finish

  8. Step 3 – Move writing operations to background • Identify the big win operations – what common tasks will the user want to be able to perform in the background? • Trade-off is added complexity of code versus important responsiveness gains • Need to be aware of concurrency requirements of code you’re calling: locks acquired, etc • Be aware of deadlock risks and know avoidance strategies

  9. Step 3 (continued) • Avoid hold and wait: • ISchedulingRule: allows jobs to specify requirements before they even start (two phase locking). • Impossible to hold a rule and be waiting for a rule • Avoid holding locks while client code is called • Avoid syncExec and use asyncExec where possible • Avoid circular wait • Always acquire locks in a consistent order • Preemption: • If all else fails, preempt the thread that introduced deadlock and report error in log. This happens for free with ILock and ISchedulingRule

  10. UI presentation of jobs • Generic job feedback • Status line animation • Progress view • User initiated jobs need strong feedback (out of box) • User wants to feel in control • When did it start/finish? • What are the results? • View-specific jobs • Tell the user if the view is busy or invalid (half-busy cursor, title font) • System jobs: no feedback at all • Must not block the user

  11. Further reading • Examples plug-in (dev.eclipse.org/home/eclipse: org.eclipse.ui.examples.job • http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-core-home/plan_concurrency.html • GUI Bloopers, Jeff Johnson – Chapter 7: Responsiveness Bloopers • Concurrent Programming in Java, Doug Lea • Modern Operating Systems, Andrew S. Tanenbaum

More Related