1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
|
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Author" CONTENT="James CE Johnson">
<TITLE>ACE Tutorial 013</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#000FFF" VLINK="#FF0F0F">
<CENTER><B><FONT SIZE=+2>ACE Tutorial 013</FONT></B></CENTER>
<CENTER><B><FONT SIZE=+2>Multiple thread pools</FONT></B></CENTER>
<P>
<HR WIDTH="100%">
<P>
My intent with this tutorial was to derive from ACE_Data_Block instead
of ACE_Message_Block so that we could leverage the reference counting
nature of that object.
<P>
Along the way, I sort of got distracted... What I ended up with is a
poor excuse for ACE_Stream that implements a simple state machine.
<P>
The application is built around a thread pool where the pool's svc()
method takes work units from the message queue for processing. As
each unit is taken from the queue, the process() method is invoked to
do some work. The twist is that after processing the message, we
enqueue it into another thread pool to do more work. This continues
through a chain of thread pools until the last where the unit's fini()
method is called for finishing up any outstanding work.
<P>
The chain of thread pools is uni-directional using a singly-linked
list of Task derivatives. Each pool has the same number of tasks in
order to keep things simple.
<P>
Kirthika's abstract:
<UL>
In this tutorial, a singly linked list of thread-pools, each of which is
a subtask and which acts as the finite state machine node, is used to
simulate a finite state machine.
<P>
A task is created with a number of subtasks. Once the message block is
obtained from the queue, it is verified to see whether a task has a
subtask. If so, it is forwarded to the subtask. Thus the mesage
traverses over the whole list. As a safety measure for destroying the
block after it goes through the whole list, an effective and simple
Memory Leak Detector has been implemented. It is a counter which
increments when the object where it resides is created and decrements on
its deletion.
<P>
Another optimisation from the previous tutorials on Message Queues, is
the bundling of the Data block within the Message Block. The Data block
provides reference counting, so duplication of data is avoided. It is
deleted only when its reference count drops to zero. Now updating
this count between threads call for synchronisation and in comes the
ACE_Mutex, a lock which takes care that the counting is thread-safe.
<P>
Although the example isn't a full-fledged Finite State Machine,
i.e. it has to be tweaked to be able to jump states on different inputs,
it definitely proves to be a great lesson and introduces us to quite a
few new ACE classes and the ways they can be mixed and matched to
produce the end-system desired.
</ul>
<P><HR WIDTH="100%">
<CENTER>[<A HREF="../online-tutorials.html">Tutorial Index</A>] [<A HREF="page02.html">Continue This Tutorial</A>]</CENTER>
|
