Quantitative Analysis
Parallel Processing
Numerical Analysis
C++ Multithreading
Python for Excel
Python Utilities

I. Installation.
II. Threading primitives.
III. NonBlockingQueue.
IV. ThreadPool.
V. ThreadMaster.
VI. OTS Scheduler.
1. Scheduler implementation.
2. Customization of Scheduler. Interfaces IOrigin and IProxy.
3. Acceptance test for the Scheduler.
VII. Bibliography
Downloads. Index. Contents.

OTS Scheduler.

onsider the following example situation (see the figure ( Example situation )).

Example situation
Example situation

We would like to broadcast present value of a bond trade under intense inflow of market information. The present value depends on the "(A) Interest Rate Curve" object and "(B) Hazard Rate Curve" object. The (A) and (B) receive market information and become out-of-date after receiving every piece of data. In addition, (B) is dependent on (A), hence, if (A) becomes out-of-date then so does (B). Bringing (A) or (B) up to date is a relatively lengthy quantitative operation. While (B) is being updated, the (A) may become out-of-date. Therefore, if we postpone processing of (C) until both (A) and (B) are brought up-to-date then (C) might never get any processing time.

If the CPU is slow or the flow of market data is too intense then reaching perfect sync with the market is not possible. We could, however, reach a sync with a state of the market as it was a small while ago. To do so we need to schedule the processing in optimal way. We need to keep track of incoming data to determine which object needs processing and which does not need it. We need to keep track of dependencies between objects. These are the tasks performed by the ots::scheduler module presented in this section.

The ots::scheduler has the following properties:

1. The delay in processing is the same for every node in the dependency tree.

2. The delay increases linearly with the number of out-of-date nodes in the tree.

3. The delay decreases linearly with increase of the CPU power.

4. The delay has a constant asymptotic behavior when the inflow of data intensifies.

5. The ots::scheduler grabs all memory that it needs for all processing when a new node is added. It does not need more memory if the flow of data intensifies. It does not do heap operations unless nodes are added or removed.

6. The processing threads never wait for each other while accessing shared data unless there is nothing else to do.

7. The scheduling tasks are performed in optimal way.

8. If boost::thread_resource_exception is thrown then the scheduler kills and restart the offending thread and updates the entire tree under a single thread for one cycle. Then the normal processing is resumed. The ots::scheduler graciously handles all other exceptions.

9. The ots::scheduler assumes nothing about the client program design.

10. An object, registered with the ots::scheduler (has a corresponding node in the ots::scheduler tree), does not get another update request until it returns from the current request. This, in particular, means that the ots::scheduler takes care of most multiprocessing issues in the program. It allows to write the client code in thread-oblivious way but does not require it.

The next picture outlines a possible design with the ots::scheduler module.

Application design with Scheduler
Application design with Scheduler

The business objects A,B,C,... are placed on the Grid and await an order to update from the Scheduler. The Router redirects market information to the objects on the Grid and notifies the Scheduler every time some object receives a piece of market data. The Scheduler sends the "execute now" messages to the grid.

1. Scheduler implementation.
2. Customization of Scheduler. Interfaces IOrigin and IProxy.
3. Acceptance test for the Scheduler.

Downloads. Index. Contents.

Copyright 2007