1 / 11

Concurrency Experience Report: Team/CVS

Concurrency Experience Report: Team/CVS. Michael Valenta IBM Canada Eclipse Platform Team. dev.eclipse.org:/platform-vcm-home/docs/online/team3.0/Concurrency Experience Report.ppt. Overview. Introduction Concurrency in 4 parts Responsive fetching of view contents

jaldana
Download Presentation

Concurrency Experience Report: Team/CVS

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. Concurrency Experience Report: Team/CVS Michael Valenta IBM Canada Eclipse Platform Team dev.eclipse.org:/platform-vcm-home/docs/online/team3.0/Concurrency Experience Report.ppt

  2. Overview • Introduction • Concurrency in 4 parts • Responsive fetching of view contents • Repositories view, history view and quick diff • Handling intermittent resource delta notification • could happen anytime • Background operations on workspace resources • Checkout, synchronization, commit, etc. • Thread safety of data structures • Synchronization state maintenance and change notification • Summary

  3. Introduction • Team/CVS was a test bed for concurrency • Perceived as one of the areas with the greatest gain • Good test of what is required • Areas where concurrency can help • UI affordances • Deadlock avoidance • Identify areas of greatest gain • What was done in 3.0: • Many CVS operations are run in the background • Team synchronization framework supports background operation

  4. Part 1: Fetching view contents in the background • The easiest task to convert to concurrency since it is independent of workspace resources. • Useful tasks include: • Background population of trees • Example in org.eclipse.ui.examples.job of dev.eclipse.org • Used scheduling rule to prevent multiple fetches from same repository • Background population of history view • CVS specific • Quick Diff: background fetching and caching of remote contents • CVS specific • Uses caching scheme available as API in org.eclipse.team.core

  5. Part 2: Resource Delta Handling • Can now get a post-change delta without a preceding pre or post auto-build event. • Only matters when non-builders reconciled state in pre or post-auto-build listeners. • CVS did this • State reconciliation now delegated to a background job • Events are queued and processed asynchronously • Result notifications are batched as needed

  6. Part 3: Team Operations in the Background • Job configuration • Foreground vs. Background? See part 4 • Modifies workspace resources? • Use a scheduling rule • Background: WorkspaceJob • Postpones auto-build • Foreground: IWorkspace#run(…) • Do not allow intermittent resource deltas • IWorkspace#run(rule, AVOID_UPDATE, …) • Team provides helper class to run operations • TeamOperation

  7. Part 4: Thread Safety of Data Structures • By far, the hardest part of concurrency • Used Ordered Locks to protect data structure integrity • Obtain at finest granularity and hold for a short time • Always obtain before modifying meta-info resource • Used resource scheduling rules to • Ensure exclusive write access to resources • Batch change notification • Never write if scheduling rule not obtained • Have provided example/reusable thread safe synchronization management components • Used by FTP and WebDAV plugins

  8. Repository Provider Checklist • Use ordered locks to protect data structures • Deadlock detection • Very fine granularity and hold for short time • Use scheduling rules to batch workspace modifications • Project or lower granularity • Remember to respect lock ordering • Provide a resource rule factory • The default rule factory locks workspace • Concentrate effort on areas of largest gain • What do users do multiple times a day • Exploit synchronization API • More on this tomorrow

  9. Rule of thumb: Resource Scheduling Rules • Use finest resource scheduling rule granularity possible • But keep in mind that there is a performance tradeoff • i.e. use a rule that encompasses a reasonable operation or sub-operation • For CVS/Team, project rule is used in most cases • This is due to how CVS commands are implemented • Avoid using a rule if possible when workspace resources are not being modified • CVS needs some work in this area

  10. Rule of Thumb: Ordered Locks • An ordered lock is a lock with • Deadlock detection and recovery • Knowledge of scheduling rules/syncExec/asyncExec • Ensure locks are obtained in a consistent order • Avoids textbook deadlock case • Include other types of locks in ordering (e.g. scheduling rules) • Do not obtain locks in resource delta handler • If this could change fixed order of acquisition • Do not invoke client code while holding a lock • Because order can easily be broken

  11. Summary • Some CVS workflows were drastically improved by concurrency • Biggest gains were in day-to-day workflows • For CVS this is in synchronizing, updating and committing • For example, if is now possible to work over a slow connection but keep up-to-date with many projects (i.e. entire Eclipse platform) • Other areas are helpful but of less impact • Largest effort was in making synchronization data structures thread safe • Use of ordered locks and scheduling rules to prevent deadlock and maintain integrity • Responsiveness responsibilities • Team/CVS only need deal with availability • Platform handles appropriate feedback

More Related