migration of TrackDetectorAssociator
removed old hard-coded seeding configuration
The variable remainingEvents_ may be read by multiple threads simultanously so must be atomic
First version to actually process multiple events concurrently

This version uses a TBB task per Stream to process Events with a mutex used to protect the Source in a critical section. This is sufficient to test the thread safety of the framework internals.
Propagate exceptions thrown during processing to the main thread

The EventProcessor now uses the new C++11 std::exception_ptr, std::current_exception() and std:rethrow_exception() to capture a thrown exception in a thread processing an event and then transfer that exception to the main thread to be rethrown. We use an std::atomic to provide thread safe update of the std::exception_ptr member data in the case of multiple processing threads having an exception. In such a case, only one of the exceptions will be kept.
Added classes to managed resources shared by multiple modules

The SharedResourcesRegistry is the centralized place where resources are registered and where the framework can get SharedResourcesAcquirer instances. These two classes work together to allow safe sharing of non-thread safe resources between modules. A unit test is included to test the two classes.
Switched to using recursive_mutex and moved SharedResourcesAcquirer.h to interface

In order to more easily accommodate unscheduled execution, I switched from using a mutex to a recursive_mutex. This will be less performant since the locks will be held longer than might be needed but it is easier to implement initially. A more performant way would be to release the locks temporarily while we are doing a ‘edm::Event::getBy*’ call.
Made legacy modules thread safe

Now uses a std::mutex to guarantee a module instance is only processing one event at a time. Also uses a edm::SharedResourcesAcquirer to get the legacy resource and therefore guarantee only one legacy module is running at a time.
Use the SharedResourcesAcquirer when a ‘one’ type module declares a SharedResource

All ‘one’ style base classes now hold a SharedResourcesAcquirer and use a new virtual function ‘createAcquirer()’ which by default returns an empty SharedResourcesAcquirer instance. If the module declares the use of a ‘SharedResource’ then the ‘createAcquirer()’ method will be overridden and return an instance with the needed resources. To facility this, edm::one::imll::SharedResourcesUser had to be changed to a templated class.
Need to explicitly instantiate the SharedResourcesUser templated class

The SharedResourcesUser class was just changed to a template. As with the other implementor types, this needs to be explicitly instantiated.
Added missing mutex includes
commented out debug printouts
Make access to EventSetup thread safe

Use a global mutex to serialize access to all EventSetup modules and sources. This is overkill but guarantees that if any two modules/sources are sharing a non-thread safe resource we don’t have a problem.  Changed two of the mutable to std::atomics since they are read/written outside of the critical section guarded by the mutex.
Use less strict acquire/release memory ordering for DataProxy cache info
Added a special resource for DelayedReader

To allow a DelayedReader to synchronize with itself we want to use a SharedResourcesAcquirer. However, the normal procedure of declaring a resource and then only after all resources have been declared do we get an acquirer isn’t appropriate for this case. Therefore we provide a special resource just for this case.
DelayedReader can now use a SharedResourcesAcquirer

If a DelayedReader needs to synchronize with itself (and possibly with the Source) the inheriting class can override the sharedResources_() method. The method is used when data products are requested from the DelayedReader.
If the Source also needs to synchronize with the DelayedReader the inheriting class can override resourceSharedWithDelayedReader_() and return a SharedResourcesAcquirer which uses the same resource as the DelayedReader. The EventProcessor will acquire the resource before calling methods on the Source.
Use new InputSource and DelayedReader APIs to synchronize

Given that we can’t be reading from the InputSource at the same time as we fill a branch via the RootDelayedReader, we implement the new APIs to allow both the PoolSource and the RootDelayedReader to share a ‘resource’.
clear the event selector in a thread safe manner

Moved the sentry used to clear the event selector at the end of each event processing to be within the mutex. This makes sure all updates on that object are done in the same critical section.
Have delayed reading of provenance synchronize with all other reads from PoolSource
Tell ROOT we are going to use multiple threads

For ROOT 5 we must load all plugins before starting the threaded event processing. Therefore I added an option to turn on loading of all dictionaries up front. Also, ROOT requires us to call TThread::Initialize() in order to get ROOT to use internal mutexes.