Create "PelotonMain" object

[apavlo]

There is no single object that encapsulates the different objects in the system. Both @malin1993ml and @sid1607 have the problem that they need to maintain stateful objects that are used in different parts of the system but there is no single location to put them. The TrafficCop object is really just a bunch of static methods, so it's not really the right place.

I propose that create a new class called PelotonMain that is responsible for instantiating the different parts of the system and connecting them together (e.g., thread pools, optimizer, traffic cop, executors). We can make this a singleton object that can be retrieved by any part of the system that needs it (need to think about this, it might be a bad idea).

[jessesleeping]

From my experience, for the following components, we should have the orders below:

• epoch manager -> gc manager
• epoch manager -> log manager -> transaction worker threads / networking threads

Currently their initialization order depends on whose GetInstance() method gets called first... I have to manually call the GetInstance() to enforce the order in our micro-benchmarks...

For the implementation, I think it's good to have a class that is in charged of all the initialization logic. May be each component (e.g. epoch_manager, gc_manager, thread_pool) should have a uniform interface of Init(...) and Start(...), where Init() initializes the parameters of the component and Start() spawns threads of that component. The centralized init logic can call Init() and Start() of different components to enforce the order.