© 2004 ibm corporation | boston ma, april 19, 2004 john arthorne, eclipse platform core team the...

© 2004 IBM Corporation | Boston MA, April 19, 2004

John Arthorne, Eclipse Platform Core Team

The Road to Responsiveness in Eclipse 3.0

2 The road to responsiveness | © 2004 IBM Corporation

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


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


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


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


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


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


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


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


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


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

© 2004 ibm corporation | boston ma, april 19, 2004 john arthorne, eclipse platform core team the...

Documents