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

I. Installation.
II. Threading primitives.
III. NonBlockingQueue.
1. NonBlockingQueue design.
2. Simplest example with NonBlockingQueue.
3. NonBlockingQueue prototypes.
A. NonBlockingQueue data fields.
B. NonBlockingQueue::push member function.
C. NonBlockingQueue::pop member function.
D. NonBlockingQueue::Element.
E. NonBlockingQueue::Node.
4. Python-based acceptance test of NonBlockingQueue.
IV. ThreadPool.
V. ThreadMaster.
VI. OTS Scheduler.
VII. Bibliography
Downloads. Index. Contents.

NonBlockingQueue prototypes.


he following is the public interface of the NonBlockingQueue.

Lines (5,6): The purpose of Node and Element is described in the general design section ( NonBlockingQueue design section ).

Line (12): We do not insert Data. Instead, we insert the Node object that has reference to a Data. Such design allows for optimizations and reduces the burden of exception safety. The push and pop operations do not allocate or release heap memory blocks. The "volatile" keyword is present in agreement with the principles ( Multi threaded design rules ).

Line (14): This is a thread-safe extraction of some Node. There is no deterministic order of extraction.

Line (15): This is a debugging feature. It provides representation of NonBlockingQueue but does no global locking. Hence, it creates such representation while NonBlockingQueue may be modified. The argument DataToString provides a way to serialize the Data. The regular "<<"-based approach is not applicable because some mutex-wise locking of Data has to be involved. The user has to be mindful of the order of locking. The regular use is this: first, lock Data, then do something with it including queue operations that include Element lock and Node lock. The toString operation has to do the opposite: lock Element, lock Node and then call DataToString which includes Data lock. Such operation, if done naively, will eventually deadlock. Therefore, the DataToString has to do a try-lock inside. This is the reason it returns a pair. If the try-lock fails then the user code may choose to return (false,"whatever"). If this is the case, then the toString code releases Node and Element, waits a short while and attempts again from the same position in the double linked list.

01\ template <class Data>

02\ class NonBlockingQueue : boost::noncopyable

03\ {

04\ public:

05\ class Node;

06\ class Element;

09\ public:

10\ NonBlockingQueue();

11\ ~NonBlockingQueue();

12\ void push( volatile Node& data ) volatile;

14\ volatile Node& pop() volatile;

15\ std::string toString(

const boost::function1<std::pair<bool,std::string>,volatile Data*>& DataToString

) const volatile;

16\ };




A. NonBlockingQueue data fields.
B. NonBlockingQueue::push member function.
C. NonBlockingQueue::pop member function.
D. NonBlockingQueue::Element.
E. NonBlockingQueue::Node.

Downloads. Index. Contents.


















Copyright 2007