Similar to http://stackoverflow.com/questions/8738160/eclipse-jobs-api-for-a-stand-alone-swing-project This question mentions the Jobs API from the Eclipse IDE:

...The disadvantage of the pre-3.0 approach was that the user had to wait until an operation completed before the UI became responsive again. The UI still provided the user the ability to cancel the currently running operation but no other work could be done until the operation completed. Some operations were performed in the background (resource decoration and JDT file indexing are two such examples) but these operations were restricted in the sense that they could not modify the workspace. If a background operation did try to modify the workspace, the UI thread would be blocked if the user explicitly performed an operation that modified the workspace and, even worse, the user would not be able to cancel the operation. A further complication with concurrency was that the interaction between the independent locking mechanisms of different plug-ins often resulted in deadlock situations. Because of the independent nature of the locks, there was no way for Eclipse to recover from the deadlock, which forced users to kill the application...

...The functionality provided by the workspace locking mechanism can be broken down into the following three aspects:

• Resource locking to ensure multiple operations did not concurrently modify the same resource
• Resource change batching to ensure UI stability during an operation
• Identification of an appropriate time to perform incremental building

With the introduction of the Jobs API, these areas have been divided into separate mechanisms and a few additional facilities have been added. The following list summarizes the facilities added.

• Job class: support for performing operations or other work in the background.
• ISchedulingRule interface: support for determining which jobs can run concurrently.
• WorkspaceJob and two IWorkspace#run() methods: support for batching of delta change notifications.
• Background auto-build: running of incremental build at a time when no other running operations are affecting resources.
• ILock interface: support for deadlock detection and recovery.
• Job properties for configuring user feedback for jobs run in the background.

The rest of this article provides examples of how to use the above-mentioned facilities...

In regards to above API, is this an implementation of a particular design pattern? Which one?