Prediction-Based Dynamic Thread Pool Management of

Agent Platform for Ubiquitous Computing*

Ji Hoon Kim, Seungwok Han, Hyun Ko, and Hee Yong Youn**

School of Information and Communication Engineering

Sungkyunkwan University, 440-746, Suwon, Korea
{ji_hoon,lovedonny,osthein,youn}@ece.skku.ac.kr

Abstract. The applications for ubiquitous system require to effectively utilize

the resources distributed in the environment to provide intelligent services to
the users. In order to satisfy the requirement, the applications need to be devel-
oped using intelligent agents based on multi-thread model. In this paper we
propose the prediction-based dynamic thread pool management scheme for
maximizing the resource utilization. In the proposed scheme the number of
threads in the pool is predicted by modeling the rate change in the requested
number of threads using the Gaussian distribution. An experiment shows that
the proposed scheme outperforms the existing representative models in terms of
response time for thread generation in practical operational environment.

1 Introduction

Recently, advanced technologies in the wireless communication, mobile computing,

intelligent agent, and real-time system have enabled a new class of applications re-
quiring ubiquitous access to the information anywhere and anytime. The applications
for ubiquitous system need not only to effectively utilize the resources distributed in
the environment but also provide intelligent services to the users. In order to satisfy
such requirement, the applications require a high degree of flexibility and adaptability
in order to deal with heterogeneous platforms and dynamic ubiquitous environments.
Also, they are preferred to be implemented using intelligent agents and agent platform
providing customized services to each user [1].
The agent platform usually employs the multi-thread model supporting concurrent
services to multiple agents. The agent platform creates a thread whenever an agent
requests it. If many agents request a thread for a short task, the response time can
become very large. In this situation the agent platform needs to employ an approach
for allowing small response time. This is an important issue especially for the applica-
tion providing interactive services to a number of users. Numerous methods reducing
the overload of thread management have been reported in the literature [2].
*
This research was supported by the Ubiquitous Autonomic Computing and Network Project,
21st Century Frontier R&D Program in Korea and R01-2006-000-10954-0, Basic Research
Program of the Korea Science & Engineering Foundation.
**
Corresponding author.

J. Indulska et al. (Eds.): UIC 2007, LNCS 4611, pp. 1098–1107, 2007.
© Springer-Verlag Berlin Heidelberg 2007
 Prediction-Based Dynamic Thread Pool Management of Agent Platform 1099

In this paper we propose the prediction-based dynamic thread pool management

scheme for maximizing the resource utilization. In the proposed scheme the number
of threads in the pool is predicted by modeling the rate change in the requested num-
ber of threads using the Gaussian distribution. An experiment shows that the proposed
scheme outperforms the existing representative bounded thread pool models in terms
of response time for thread generation in practical operational environment.
The rest of the paper is organized as follows. Section 2 describes an overview of
agent platform and the strategies for multi-threading. Section 3 presents the proposed
scheme, and Section 4 evaluates it. Section 5 concludes the paper with some remarks.

2 The Related Work

Agents can be defined to be autonomous problem solving computational entities

capable of effective operation in dynamic and open environments [6]. The main char-
acteristics of the agents are autonomy, intelligence, mobility, and social ability. Addi-
tional characteristics are reactivity against the change in the environment, veracity for
prohibiting wrong information, and rationality for supporting rational method. The
agents can be classified into multi-agent and mobile-agent. The multi-agent system is
used for handling complex operations requiring collaboration between the agents. The
mobile-agent moves through the network to process the tasks.
The agent platforms have to support agent communication language such as ACL
(Agent Communication Language) and KQML (Knowledge Query Manipulation
Language) to allow collaboration between the agents residing in different agent plat-
forms. The agents provide the designers and developers with a way of structuring an
application around autonomous, communicative elements and lead to the construction
of software tools and infrastructure supporting the design metaphor [7]. The widely
recognized agent platforms are JADE [8] and Aglet [9].
The FIPA (Foundation for Intelligent Physical Agents) [10] agent management
specifications identify the roles of the key agents required for managing the platform,
and describe the language and ontology of agent management. The main modules of a
standard agent platform are AMS (Agent Management System), ANS (Agent Name
Server), and DF (Directory Facilitator). The AMS is the agent that exerts supervisory
control over access to and use of the platform. It is responsible for maintaining the
directory of resident agents and handling their life cycle. The ANS is a server acting
as a registry or white pages of agents, storing agent names, host machines, and port
numbers in its cache. It helps the platform inter-agent communication by providing a
mechanism for locating the agents. The DF is the agent providing yellow page ser-
vices to the agent platform. It supports a way to find an agent existing in the network.
Various thread models have been proposed. The thread-per-request model [3] cre-
ates a worker thread for each request, and destroys it after finishing the request. This
model handles each request from a client in a separate thread of control. Its main
advantage is that it is straightforward to implement. This model is useful for the serv-
ers handling the requests of long duration such as database queries from multiple
clients. The disadvantage is, however, that it can consume a large amount of resources
1100 J.H. Kim et al.

if many clients generate the requests simultaneously. Moreover, it is inefficient for

short-duration requests causing excessive thread creation overhead. In addition, it is
not suitable for real-time applications since the overhead of spawning a thread for
each request is non-deterministic.
The worker thread pool model [4] is a variation of the thread-per-request model
that amortizes the thread creation costs by pre-spawning a pool of threads. This model
is useful for the servers wanting to bind the resources they consume. The client re-
quests can be executed concurrently until the number of simultaneous requests ex-
ceeds the number of threads in the pool. At this point, additional requests must be
queued until a thread becomes available.
When the watermark thread pool model [5] is used, it spawns a pre-established
number of threads instead of creating one new thread each time a connection request
arrives. This model has been designed in such a way that it can be easily customized
with low and high watermark used for the decision of the moment of thread regenera-
tion and elimination, respectively.

3 The Proposed Scheme

3.1 The Dynamic Thread Pool

The number of threads needs to be dynamically controlled to maximize the perform-

ance and utilization of the system resource. The basic approach here is to create and
delete the threads in advance. When the number of agent requests increases, threads
are created in advance properly. When the number of agent requests decreases, it does
not reduce the number of threads quickly. This is to avoid unnecessary overhead of
thread creation/deletion occurring when the number of threads increases shortly. Also,
if the variation in the thread increment/decrement is low, the control frequency is
reduced. Otherwise, it is increased for timely adjustment. Fig. 1 shows the number of
threads, n, as time moves. Here variable nt is defined as follows.
nt = {x | x is the number of threads in the system at time t } (1)

Fig. 1. The number of threads as time moves

 Prediction-Based Dynamic Thread Pool Management of Agent Platform 1101

The variant (slant) of the thread number at time t, at,and set A of at are defined as
follows.
nt − nt −Δt
a t = {x | x is the variant at time t} = (2)
t − Δt

A = {x | x is the set of at under coverage} (3)

fexpected(t2, t1) is the number of threads at time t2 predicted at time t1.
f expected (t2 , t1 ) = {x | x is the expected nt2 at time t1}
(4)
= at1 ⋅ t2

Δtdelay decides the prediction frequency, and one thread is created in Δtmin . The
observation error function, ferror, and the resource exhaustion in system k, resourcek,
are defined as follows.
Δtdelay = {x | x is the time delay between two consequtive predictions}
Δtmin = {x | x is the time taken to generate one thread} (5)
k ⊂ Z , ∀Δtdelay Δt delay = k ⋅ Δtmin

f error (t ) = {x | x is the expected value of error at time t}

(6)
= f expected (t , Δtdelay ) − nt
The value of ferror gets bigger when the predicted value obtained by Expression (4)
is varied from t1 to t2 and t3 as shown in Fig. 1. The error decreases as the prediction
frequency is reduced. However, the overhead gets larger if the prediction frequency
increases. This relationship can be expressed as follows.
1
ferror ∝ Δtdelay , resourcek ∝ (7)
Δtdelay
The prediction frequency needs to be properly adjusted according to the rate of the
change in the number of threads. First, we need to define the variable representing the
sampling rate.
Δtcoverage : the number of samplings (8)

In this paper Δtcoverage is set to 40, which was obtained by experiment. It sets aver-
age and dispersion of the slant at to 40 per hour. Using this parameter, the Gaussian
irregularity variable on variant value at is obtained as follows.
/ 2σ 2
e− ( x−m )
2

f AΔt ( x) = (9)
coverage
2πσ 2
1102 J.H. Kim et al.

Fig. 2. The graph of Gaussian probability density function with m = 5 and σ= 5

With the average and dispersion of variant at of m = 5 and σ= 5, the graph looks as
follows.
If the change of the slant value at is within 70% of the calculated value through the
Q-function from center spot (below 3 or over 7 in the graph above), we decrease or
increase Δtdelay by one, respectively. The process is formalized as follows.

mAΔt : average of AΔtcoverage , σ AΔt : standard deviation of AΔtcoverage

coverage coverage

⎛ at − mAΔt ⎞
if ∀at , 2Q ⎜ coverage
⎟ ≥ 0.7 then Δtdelay = Δtdelay − Δtmin
⎜ σ AΔt ⎟
⎝ coverage ⎠
⎛ at − mAΔt ⎞
if ∀at , 2Q ⎜ coverage
⎟ < 0.7 then Δtdelay = Δtdelay + Δtmin (10)
⎜ σ AΔt ⎟
⎝ coverage ⎠

A waiting thread in the thread pool becomes active when a request arrives. An ac-
tive thread becomes a waiting thread after the operation finishes. If a waiting thread
has been waiting more than one idle timeout period, it deletes itself.

3.2 The Agent Platform

When the agent platform starts to operate, it creates a thread pool. The size of the pool
can be dynamically controlled by a request of an agent. In the developed agent plat-
form [1], a thread pool controller exists. It applies the prediction value calculated by
the fexpected(t2, t1) function and controls the size of the thread pool accordingly. Fig. 3
shows the agent platform architecture where the proposed scheme is employed.
The agent platform consists of the MTP (Message Transport Protocol) and the
agent platform core module. The MTP is in charge of the event-based communica-
tion, and the agent platform core module is in charge of the management of platform
and agents. The MTP layer contains HTTP Communication module built for the
communication between the agents. An agent has a HTTP server and client module in
itself. When a message is received, the HTTP server processes it. When a message is
sent, the HTTP client is used for the communication. It also contains the ACL Parser
 Prediction-Based Dynamic Thread Pool Management of Agent Platform 1103

Fig. 3. The architecture of the agent platform [1][11][12][13]

module encoding and decoding the ACL messages. An agent can simultaneously send
a message to several agents through the process of ACL. The Message queue module
supports ordering and queuing of messages for receiving/sending the messages.
The agent platform core consists of Main Container, Agent Container, and
ADT(Agent Description Table). The Main Container is the main module managing the
agent platform. It contains Platform Manager handling the initialization of the agent
platform and delivery of messages from the MTP layer to the agent processing module
and Service Manager that registers and manages additional services such as reflection
module. The Agent Container manages groups of agents having similar roles or func-
tions hierarchically. It contains Life-Cycle Manager that manages the actions of an
agent as a thread and Agent Descriptor that manages the information of agent descrip-
tion such as id, address, roles, etc. The ADT is a hash table that manages the reference
information of the agents’ description using the hash key of the agent’s id.
The agent platform core uses MTP library, and it consists of one main container
and several agent containers. An agent container manages groups of agent descrip-
tions, where the agent description contains the information required for connection
and management of the agent, and status information required for life cycle manage-
ment. The agent platform monitors and manages agents as threads. The threads take
actions such as start, stop, resume, and running dynamically with the agent’s present
state.
The agent platform core consists of the parts allowing interactions among the
agents and managing the execution of agent platform. It governs the relationships
between the modules and services through the main action flow. Fig. 4 shows the
sequence among the principal modules of the agent platform core in case of initializ-
ing the agent platform, registering and releasing an agent, and delivery of message.
When the agent platform begins to operate, it creates Main Container firstly. Main
Container reads the setting file of XML format for initialization. The setting file has
the version information of the platform besides the name, address, port, and resource
information. It also creates ADT to directly access the agent description information
and Main Thread Group Table that manages the Agent Container’s reference values.
Then, it finishes the initialization to receive ACL messages by initializing the com-
munication server module of MTP.
1104 J.H. Kim et al.

Fig. 4. The main operational sequence of agent platform core

Each agent sends an ACL message to register to the agent platform. Then, the
agent platform core receives a callback message from the MTP. It confirms if it is a
message sent by the agent platform through the receiver part of ACL. After checking
the content of ACL if it is a registration message, it extracts the agent’s name, ad-
dress, port, description information, container information from the message. Then, it
examines the Agent ID from the ADT using the hash key if it has been already regis-
tered of not. If it was already registered, the platform sends a failure message indicat-
ing ‘already registered’ to the agent. After the agent is registered to the ADT, the
agent platform allocates an agent thread from the agent thread pool. The allocated
agent thread has the agent description information, and it dynamically monitors the
agent according to its state. It checks if there already exists a relevant agent container.
If not, it makes a one. Otherwise, it adds it to the existing container. Then the registra-
tion process is complete, and it sends the agent the result of the process.
When an agent sends a destroy message, the agent platform core receives an ACL
message through message callback. Then it confirms that the receiver part of that is
agent platform and the content is for deletion. It searches the ADT using the hash key
of the Agent ID, and then deletes the reference value of the relevant agent information
from the ADT. Also, it destroys the relevant agent thread from the agent thread pool
and deletes a reference of the thread from the table of agent container.
The agent platform core delivers messages to the relevant agent in case the receiver
of the ACL message entering through message callback is not the agent platform. The
sender agent does not know the receiver agent’s IP Address and Port information but
only the receiver’s name. Therefore, it requests a transmission to the agent platform.
The agent platform core searches the ADT to find the address information corre-
sponding to the receiver agent’s name. After searching the ADT, the agent platform
core receives necessary information from the agent thread module managing the agent
description information. It also talks to the relevant agent after changing the receiver’s
 Prediction-Based Dynamic Thread Pool Management of Agent Platform 1105

name and attribute value of the address, and so on. The principal sequence of opera-
tions of agent platform core is supported by the MTP, and it processes the messages at
once. Also, the platform core collects the information of management obtained by the
thread monitoring the system.

4 Performance Evaluation
In this section the proposed algorithm dynamically managing the size of thread pool is
evaluated by computer simulation and compared with the existing representative
algorithm in term of memory usage and response time. The agent platform and agent
are implemented in a PC of a Pentium-4 processor and 1 GB main memory.

10
the propos ed s cheme watermark
)c 9
es
m
( 8
e
m
it 7
es
no 6
ps
e5
R
4
1 2 3 4 5 6 7 8 9 10
Number of thread

Fig. 5. The response times when the load is high

Fig. 5 shows the response times when the load is high. Here one agent request is
generated in every 0.1 second. The thread pool controller predicts the pool size, while
the maximum idle timeout before deleting a thread is set to 0.3 second. Observe from
Fig. 5 that the proposed scheme outperforms the existing representative algorithms
when the number of thread is larger than 4. The proposed scheme requires to use
about 0.5% more memory space than the other models (7450KB vs 7330KB). If agent
request increases, the number of threads scheduled also increases. Therefore, the

8
the propos ed s cheme watermark
)c
es 7
(m
e
im
t6
es
n
o
ps
e5
R

4
1 2 3 4 5 6 7 8 9 10
Number of thread

Fig. 6. The response times when the load is low

1106 J.H. Kim et al.

response time will also increase. In this case the agent platform uses more system
resource, and reduces the response time.
Fig. 6 shows the response times when the load is low such that one agent request is
generated in every 5 seconds. In this case the watermark thread pool model uses low
watermark, and thus it acts like the worker thread pool model. Notice from the figure
that we get similar results as with high load. For memory usage, however, the pro-
posed scheme requires slightly smaller space than the watermark scheme (6300KB vs
7300KB).

5 Conclusion
The applications for ubiquitous system require to effectively utilize the resources
distributed in the environment and provide intelligent services to the users. In order to
satisfy such requirement, the applications need to be developed using intelligent
agents providing optimized services to each user. Furthermore, the platform itself
needs to be able to support platform-level service optimization.
In this paper we have proposed a prediction-based dynamic thread pool manage-
ment scheme using Gaussian distribution for maximizing the utilization of resources.
From the experiments, we showed that the proposed scheme outperforms the existing
representative thread pool models. We have also introduced a new architecture of
agent platform that provides an interactive environment between intelligent agents,
along with the operation sequence flow of registration, removal, and transmission of
agents with the proposed agent platform core. It allows both the group management
and individual management of the agents for efficiency.
As the future work, we will further optimize the dynamic thread pool management
scheme by properly adjusting the parameters used in the prediction.

References
1. Han, S., Youn, H.Y.: A Middleware Architecture for Community Computing with Intelli-
gent agents. Ubiquitous Computing & Networking System (2005)
2. Schmidt, D., Pyarali, I., Spivak, M., Cytron, R.: Evaluating and Optimizing Thread Pool
Strategies for Real-Time Cobra. ACM Sigplan Notices 36(8), 214–222 (2001)
3. Schmidt, D., Vinoski, S.: Object Interconnection: Comparing Alternative Programming
Techniques for Multi-Threaded Servers-the Thread Per-Request Concurrency Model. C++
Report, SIGS, 801(2) (1996)
4. Schmidt, D.: Evaluating Architectures for Multi-thread CORBA Object Request Brokers.
In: Seetharaman, K. (ed.) Communication of the ACM, Special Issue on CORBA 41(10)
(1998)
5. Dynamic TAO Documentation, http://choices.cs.uiuc.edu/2k/dynamicTAO/doc/
6. Luck, M., McBurney, P., Preist, C.: Agent Technology: Enabling Next Generation Com-
puting. AgentLink community (2003)
7. Jennings, N.R.: An agent-based approach for buildingcomplex software systems. Commu-
nications of the ACM 44(4), 35–41 (2001)
8. JADE, Java Agent Development framework, http://jade.cselt.it
9. IBM Japan Research Group: Aglets Workbench, http://www.trl.ibm.com/aglets
 Prediction-Based Dynamic Thread Pool Management of Agent Platform 1107

10. FIPA-Foundation for Intelligent Physical Agents, http://www.fipa.org

11. Park, A.H., Park, S.H., Youn, H.Y.: A Flexible and Scalable Agent Platform for Multi-
Agent Systems. Enformatika Transactions on Engineering, Computing and Technol-
ogy 19, 1–6 (2007)
12. Ko, H., Youn, H.Y.: Adaptive Bridging with Portable Interceptor for Efficient Integration
of Reflective Middleware. In: Ma, J., Jin, H., Yang, L.T., Tsai, J.J.-P. (eds.) UIC 2006.
LNCS, vol. 4159, pp. 669–678. Springer, Heidelberg (2006)
13. Park, S.Y., Youn, H.Y.: Message Transport Interface for Efficient Communication Be-
tween Agent Framework and Event Service. In: Gavrilova, M., Gervasi, O., Kumar, V.,
Tan, C.J.K., Taniar, D., Laganà, A., Mun, Y., Choo, H. (eds.) ICCSA 2006. LNCS,
vol. 3983, pp. 1–10. Springer, Heidelberg (2006)