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
| Date | Other Information, if necessary
© 2004 IBM Corporation | Confidential
April 19, 2004
© 2002 IBM Corporation
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
2
Concurrency Experience Report: CVS | © 2004 IBM Corporation
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
3
Concurrency Experience Report: CVS | © 2004 IBM Corporation
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
4
Concurrency Experience Report: CVS | © 2004 IBM Corporation
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-autobuild listeners.
 CVS did this
 State reconciliation now delegated to a background job
 Events are queued and processed asynchronously
 Result notifications are batched as needed
5
Concurrency Experience Report: CVS | © 2004 IBM Corporation
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
6
Concurrency Experience Report: CVS | © 2004 IBM Corporation
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
7
Concurrency Experience Report: CVS | © 2004 IBM Corporation
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
8
Concurrency Experience Report: CVS | © 2004 IBM Corporation
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 suboperation
 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
9
Concurrency Experience Report: CVS | © 2004 IBM Corporation
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
10
Concurrency Experience Report: CVS | © 2004 IBM Corporation
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
11
Concurrency Experience Report: CVS | © 2004 IBM Corporation