blob: 217a2f9bf1d70e20d9595350bb976b0fac52419c (
plain)
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
|
<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>
<HR WIDTH="100%">
<CENTER>[<A HREF="..">Tutorial Index</A>] [<A HREF="page02.html">Continue
This Tutorial</A>]</CENTER>
</BODY>
</HTML>
|
