in black and white
Main menu
Share a book About us Home
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

Excel add in development in C++ Aplications in finance - Dalton S.

Dalton S. Excel add in development in C++ Aplications in finance - Wiley publishing , 2005. - 425 p.
ISBN 0-470-02469-0
Download (direct link): exceladdindevelopmentincand2005.pdf
Previous << 1 .. 128 129 130 131 132 133 < 134 > 135 136 137 138 139 140 .. 168 >> Next

The example in this section makes no restriction on the way the interface function is used in a cell, although this is a weakness: the user is relied upon only to enter one such function per cell.
9.10.5 Organising the task list
The example in this section uses the following simple structure to represent a task. Note that a more sensible approach would be to use a Standard Template Library (STL) container class. The, some would say, old-fashioned linked list used here could easily be replaced with such a container. The intention is not to propose the best way of coding such things, but simply to lay out a complete approach that can be modified to suit coding preferences and experience.
typedef struct tag_task {
// prev task in list, NULL if this is top
// next task in list, NULL if this is last
// set by TaskList class
// set by TaskList class
// if true, processing of this task should end // PENDING,CURRENT,READY,UNCLAIMED,COMPLETE // dll-internal Excel name of caller
tag_task *prev; tag_task *next; long start_clock; long end_clock; bool break_task; short status; char *caller_name; bool (* fn_ptr)(tag_task *); // passed in function ptr
xloper fn_ret_val; // used for intermediate and final value int num_args;
xloper arg_array[1]; // 1st in array of args for this task
This structure lends itself to either a simple linked list with a head and tail, or a more flexible circular list. For this illustration, the simple list has been chosen. New tasks are added at the tail, and processing of tasks moves from the head down. A decision needs to be made about whether modified tasks are also moved to the end or left where they are. In the former case, the algorithm for deciding which task is next to be processed simply goes to the next in the list. In the latter case, it would need to start looking at the top of the list, just in case a task that had already been completed had subsequently been modified.
Miscellaneous Topics 325
The decision made here is that modified tasks are moved to the end of the list. The TaskList class, discussed below and listed in full on the CD ROM, contains three pointers, one to the top of the list, m_pHead, one to the bottom of the list, m_pTail, and one to the task currently being executed, m_pCurrent.
A more sophisticated queuing approach would in general be better, for example, one with a pending queue and a done queue, or even a queue for each state. The above approach has been chosen in the interests of simplicity.
It is important to analyse how a list of these tasks can be altered and by what thread, background or foreground. The pointers m_pHead and m_pTail will only be modified by the foreground thread (Excel) as it adds, moves or deletes tasks. The m_pCurrent pointer is modified by the background thread as it completes one task and looks for the next one. Therefore, the foreground thread must be extremely careful when accessing the m_pCurrent pointer or assuming it knows what it is, as it can alter from one moment to the next. The foreground can freely read through the list of tasks but must use a critical section when altering a task that is, or could at any moment become, pointed to by m_pCurrent. If it wants to update m_pCurrent’s arguments, then it must first break the task so that it is no longer current. If it wants to change the order of tasks in the list, it must enter a critical section to avoid this being done at the same time that the background thread is looking for the next task.
By limiting the scope of the background thread to the value of m_pCurrent, and the task it points to, the class maintains a fairly simple thread-safe design, only needing to use critical sections in a few places.
The strategy assigns a state to a task at each point in its life cycle. Identifying the states, what they mean, and how they change from one to another, is an important part of making any complex multi-threaded strategy work reliably. For more complex projects than this example, it is advisable to use a formal architectural design standard, such as UML, with integral state-transition diagrams. For this example, the simple table of the states below is sufficient.
Table 9.8 Task states and transitions for a background thread strategy
State Notes
Pending • The task has been placed on the list and is waiting its turn to be processed. • The foreground thread can delete pending tasks.
Current • The state is changed from pending to current by the background thread with a critical section • The background thread is processing the task • If the task’s execution is interrupted, its state goes back to pending
Ready • The task has been completed by the background thread which has changed the state from current to ready • The task is ready for the foreground loop to retrieve the result
Unclaimed • The foreground thread has seen that the task is either ready or complete and has marked it as unclaimed pending recalculation of the workbook(s) • If still unclaimed after a workbook recalculation, the task should be deleted
Previous << 1 .. 128 129 130 131 132 133 < 134 > 135 136 137 138 139 140 .. 168 >> Next