We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byMoises Emmott
Modified about 1 year ago
© 2004 IBM Corporation | February 5, 2004 John Arthorne, Eclipse Platform Core Jean-Michel Lemieux, Eclipse Platform Team Writing responsive UIs using the Eclipse 3.0 concurrency architecture
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation2 What we’ll cover Overview of UI responsiveness problems in Eclipse 2.1 Underlying factors affecting responsiveness Enumerate responsiveness problems and what we did about it Pointers to new API classes and methods in 3.0 How to make your own plug-ins more responsive
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation3 What do we mean by responsiveness? Responsiveness is not the same as performance Performance: how much work can be done in a given time Responsiveness: Feedback: How often is the user interface displaying accurate information and how quickly is user interaction acknowledged Availability: How often is the user interface in a state where the user can interact with it Responsiveness and performance are sometimes mutually exclusive. To keep the UI continually updated and in an interactive state affects performance. Allowing the user to do two things at once affects the performance of both.
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation4 Responsiveness in Eclipse 2.1 Responsiveness focus was on feedback Busy cursors and progress indicators Support for canceling long running operations Less focus on increasing availability Availability is often viewed simply as a performance problem Simpler programming model: no major worries about contention, deadlock, thread-safety, etc
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation5 Symptoms of poor responsiveness: feedback Long running operation run in the UI thread The UI seems locked (e.g. menu bar doesn’t repaint) The user doesn’t know what is happening Progress dialog appears but cancel button is disabled or doesn’t do anything. A progress dialog that doesn’t show accurate progress can also be confusing and give the impression that the application is stuck Buttons that don’t respond to clicks in the required 0.1 second (so we click them again, and again, and again…)
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation6 Symptoms of poor responsiveness: availability Too many blocking progress dialogs Delay when typing in an editor Delay opening views and editors
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation7 Examples of poor responsiveness Open a view or editor – wait while the part’s model is initialized and then finally shown. Contributed decorations – wait while decorators doing expensive calculation. Check out a project from CVS – wait until entire check out is complete before browsing files. Save a document - wait until auto-build is complete before continuing, even if you didn’t need it to be built immediately.
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation8 Examples of poor responsiveness (cont…) Synchronize with repository – wait while it refreshes all projects in the workspace before you can start browsing changes and doing commits and updates. Launching an application for debug/running – wait for debug connection before doing anything else Task view updating and filtering – wait while views are updating and filtering every time a marker is generated. Type a character in an editor – wait for editor to validate model.
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation9 Approach for solving feedback problems Remove long running operations from the UI thread Use new IProgressService.busyCursorWhile(IRunnableWithProgress) Caveat: moving processing to another thread can mean breaking changes to your plug-in Progress dialogs must honor cancellation Plug-ins must provide responsive cancellation by checking monitor.isCanceled() Update UI more often during operations
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation10 Approach for solving availability problems Give control back to the user as soon as possible (quick initialization) Offload expensive processing to background thread Start with the worst offenders instead of trying to solve everything at once Use a work queue to combine/buffer background processing
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation11 Problem 1: lack of common infrastructure In a pluggable environment, nobody has complete knowledge of what is happening. Hard to coordinate work to avoid bottlenecks and prevent deadlock. Leads to thrashing when everyone tries to do something at once Need a common infrastructure so tasks can describe what resources they need, how important they are, what other tasks they depend on, etc
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation12 Solution 1: new concurrency infrastructure 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 mutual exclusion Richer scheduling: run now, run later, run repeatedly Job listeners can find out when jobs start, finish
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation13 Problem 2: how does the user know what is happening in the background? UI design principle: when user initiates action, there should be feedback within 0.1 seconds What feedback is appropriate for background operations?
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation14 Solution 2: add job progress support Jobs report progress via the IProgressMonitor passed to the run() method. The UI provides the actual monitor and can display the Job. The following information can be shown: job name, task name, sub tasks, percent complete. System jobs aren’t shown to the user Progress animation hint workbench icon animation view specific progress indicator (e.g. busy/wait cursor and view animating icon)
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation15 Solution 2: add job progress support (cont…) Errors occurring in the background are important enough to interrupt the user. Progress groups: for grouping related jobs Prompt for information without interrupting the user IProgressService.requestInUI
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation16 Problem 3: UI is often in a transient state Background jobs can invalidate the state of things shown to the user The UI can be stale while the user is interacting with it Click on an error marker while the file is building Expand a folder that takes a while and start browsing another portion of the structure Resource in the Synchronize View is being committed to repository The UI can be changing as the user interacts with it Disco ball syndrome
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation17 Solution 3: transient state affordances WorkbenchPart will provide default progress hint if job is scheduled from a view or editor. Gray items that are transient or stale (examples: problem markers in Java files, resources in Synchronize View) DeferredTreeContentManager: Infrastructure for lazy population of trees shows hint that children are pending when a node is expanded. Other plug-in specific feedback should be avoided if possible to ensure that the UI doesn’t become too distracting (e.g. progress monitor shown in every view) Batch updates to prevent flashing using UIJob
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation18 Problem 4: deadlock More things in the background means greater chance of deadlock SWT syncExec is especially deadlock prone Many Eclipse APIs with hidden locks: resources, text, JDT, CVS No chance of resolving deadlock since every component rolled their own locking infrastructure
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation19 Solution 4: locks and scheduling rules ILock: re-entrant lock, like Java object monitors, except: Fairness: acquires are granted in FIFO order Aware of syncExec: carries over to UI thread ISchedulingRule: a scheduling rule can be attached to a Job Specifies when it is safe to run the job A job will not start while any job is running that has a scheduling rule that conflicts with its scheduling rule Implemented by clients – every plug-in can define their own rules Rules can be nested to form rule hierarchies
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation20 Solution 4: locks and scheduling rules (cont…) 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
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation21 Problem 5: increased contention Multiple threads compete for resources and cause contention. Heavy-handed use of locking constructs makes real concurrency difficult Contention can block the user and make responsiveness worse (the user tries to do something but is blocked by some long running operation happening in the background.
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation22 Solution 5: smaller locks and contention reporting Minimize locking by using fine-grained locks ISchedulingRule allows clients to specify hierarchies of locks When contention can’t be avoided it must be reported to the user IProgressService.busyCursorWhile() Uses traditional busy cursor and progress dialog Augments itself when progress is blocked IProgressMonitorWithBlocking allows an operation to report when it is stuck
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation23 Concurrency in the resources plug-in IResource implements ISchedulingRule Changing a resource now only locks a portion of the workspace, allowing concurrent modification of the workspace New IWorkspace.run() method uses scheduling rule to avoid locking the entire workspace Auto-build (and auto-build events) moved into background job to reduce perceived duration of operations Resource changes now broadcast periodically during operations. Example: can view files in a project that is in the middle of being checked out from the repository
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation24 Making your plug-in responsive 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 Watch for assumptions about UI thread and thread safety Step 3 – Move long writing operations to 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
Writing responsive UIs using the Eclipse 3.0 concurrency architecture | © 2004 IBM Corporation25 Further reading Examples plug-in (available soon) org.eclipse.ui.examples.jobs home/plan_concurrency.html GUI Bloopers, Jeff Johnson – Chapter 7: Responsiveness Bloopers Concurrent Programming in Java, Doug Lea Modern Operating Systems, Andrew S. Tanenbaum
Everything you always wanted to know about threading BUT WERE AFRAID TO ASK ELLIOT H. OMIYA (EHO) PRINCIPAL SDE WINDOWS DEVELOPER EXPERIENCE.
What is an Operating System? A program that acts as an intermediary between a user of a computer and the computer hardware. Operating system goals: Execute.
Business Objects Web Intelligence Business Objects Web Intelligence.
© 2009 Wellesley Information Services. All rights reserved. A comprehensive guide to SAP NetWeaver Visual Composer Dr. Bjarne Berg.
ADAMA UNIVERSITY SCHOOL OF ENGENEERING & INFORMATION TECHNOLOGIES Sem. II,2010/11 INSTRUCTOR TARIKU W OPERATING SYSTEM (IT3016)
VMware vCenter Server High Availability Product Support Engineering VMware Confidential.
Linux: The Guts By Sam Evans and John Massey. History Of Linux ❖ 1984: Richard Stallman quits his job at MIT, and starts working on the GNU project. ❖
General web design Thomas Krichel assessment You return a two-page typed assessment on a library and information science department web site.
Dr. Russ Johnson, President Improvement Quest, Inc Loveland, CO Is Critical Chain Project Management (CCPM) An All or None Deal? Dr. Russ Johnson, President.
1 PROJECT MANAGEMENT Using Microsoft Project 2000.
Testing Relational Database. Overview Once the design of a database system has been completed, the developers are ready to move into the implementation.
Windows 2008 Active Directory Configuration – Week 4 of 6 Microsoft Test: Mark McCoy MCSE, CNE, CISSP.
Methods for Software Specification Jan Kožusznik. Dept. of Computer Science Technical University of Ostrava
User Level Failure Mitigation Fault Tolerance Plenary December 2013, MPI Forum Meeting Chicago, IL USA.
Computers in the real world Objectives Understand the key ideas of the operating system Look at standard utility software and be able to describe them.
Cache & SpinLocks Udi & Haim. Agenda Caching background –Why do we need caching? –Caching in modern desktop. –Cache writing. –Cache coherence. –Cache.
| © 2011 Destination ImagiNation, Inc. Interference and Destination ImagiNation® How is Destination ImagiNation® different from other competitions?
1 GREY BOX TESTING Web Apps & Networking Session 10 Boris Grinberg
Computing Higher - SD Process – Topic 2 St Andrew’s High School Unit 2 Software Development Process.
File Concept A file is a named collection of related information that is recorded on secondary storage. A file has a define structure, which we must know.
Chapter 17: Recovery System Failure Classification Storage Structure Recovery and Atomicity Log-Based Recovery Shadow Paging Recovery With Concurrent Transactions.
OverviewButtons & linksSettingsAdvancedExit Menus Help Interactive PowerPoint: an interactive guide Andrew Garth Sheffield Hallam University If you can.
By Zahira Gonzalez Time Management. To do list tips Try to spend 5-10 minutes each day on planning your activities with a daily to do list. Start your.
IUCN (International Union for Conservation of Nature) SIS self-teach guide. Version 1.1 (27 th July 2012) The IUCN Species Information Service (SIS) Version.
Project Management in Team Software Projects The primary challenge of project management is to achieve all of the goals of the project charter while adhering.
Help Desk Procedures Topic: Tasks of the Help Desk Operator Written by Greg Webb while at Information Technology, Sydney Institute of Technology. Current.
An Introduction to Object Modeling An Introduction to Object Modeling The approach of using object modeling during systems analysis and design is called.
Mobile App Development & Localisation Eric Chubb Alchemy Software Development 14 th June 2012.
©Silberschatz, Korth and Sudarshan18.1Database System Concepts Chapter 18: Database System Architectures Centralized Systems Client--Server Systems Parallel.
© 2016 SlidePlayer.com Inc. All rights reserved.