U.S. patent application number 13/887422 was filed with the patent office on 2014-11-06 for lock-free creation of hash tables in parallel.
The applicant listed for this patent is International Business Machines Corporation. Invention is credited to Tim Kaldewey, Guy M. Lohman, Peter B. Volk.
Application Number | 20140330801 13/887422 |
Document ID | / |
Family ID | 51842055 |
Filed Date | 2014-11-06 |
United States Patent
Application |
20140330801 |
Kind Code |
A1 |
Kaldewey; Tim ; et
al. |
November 6, 2014 |
LOCK-FREE CREATION OF HASH TABLES IN PARALLEL
Abstract
A hash table is created in parallel without requiring a lock or
random accesses to memory. The hash table of a database system is
logically partitioned and a separate thread is assigned to each
partition of the hash table. As many separate threads as can fit
their corresponding hash table partitions into the processor's
cache are executed in parallel with other threads without a lock.
Execution of a number of separate threads includes: scanning an
input data table for a thread's partition and applying a hash
function to each key, inserting data of keys that hash to the
thread's partition into the thread's partition, and ignoring keys
that do not hash to the thread's partition.
Inventors: |
Kaldewey; Tim; (San Jose,
CA) ; Lohman; Guy M.; (San Jose, CA) ; Volk;
Peter B.; (Atlanta, GA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
International Business Machines Corporation |
Armonk |
NY |
US |
|
|
Family ID: |
51842055 |
Appl. No.: |
13/887422 |
Filed: |
May 6, 2013 |
Current U.S.
Class: |
707/698 |
Current CPC
Class: |
G06F 16/2255
20190101 |
Class at
Publication: |
707/698 |
International
Class: |
G06F 17/30 20060101
G06F017/30 |
Claims
1. A method of lock-free creation of partitioned hash tables in
parallel, comprising: partitioning a hash table of a database
system; assigning a separate thread to each partition of the hash
table; and executing a number of the separate threads in parallel
with other threads without a lock, the executing for each of said
number: scanning an input data table for a thread's partition and
applying a hash function to each key; inserting data of keys that
hash to the thread's partition into the thread's partition; and
ignoring keys that do not hash to the thread's partition.
2. The method of claim 1, wherein the scanning of the input data
table results in strictly sequential memory accesses.
3. The method of claim 1, wherein the contents of the thread's
partition are flushed to main memory in response to completing the
executed thread.
4. The method of claim 1, wherein each partition size is less than
or equal to a cache size of the processing device.
5. The method of claim 1, wherein an index is created for active
buckets of the partition such that inactive buckets of the
partition are no longer referenced and are automatically flushed to
main memory.
6. The method of claim 1, wherein overflow data, in the partition,
are stored in separate overflow buckets to be processed by another
thread.
7. The method of claim 1, wherein an input queue is provided for
each partition, enabling a thread processing of a preceding
partition to add overflow data to a subsequent input queue.
8. A database system of lock-free creation of partitioned hash
tables in parallel, comprising: a memory having computer readable
instructions; and a processor for executing the computer readable
instructions, the instructions comprising: partitioning a hash
table of a database system; assigning a separate thread to each
partition of the hash table; and executing a number of the separate
threads in parallel with other threads without a lock, the
executing for each of said number: scanning an input data table for
a thread's partition and applying a hash function to each key;
inserting data of keys that hash to the thread's partition into the
thread's partition; and ignoring keys that do not hash to the
thread's partition.
9. The database system of claim 8, wherein the scanning of the
input data table results in strictly sequential memory
accesses.
10. The database system of claim 8, wherein contents of the
thread's partition are flushed to main memory in response to
completing the executed thread.
11. The database system of claim 8, wherein each partition size is
less than or equal to a cache size of the processor.
12. The database system of claim 8, wherein an index is created for
active buckets of the partition such that inactive buckets of the
partition are no longer referenced and are automatically flushed to
main memory.
13. The database system of claim 8, wherein overflow data, in the
partition are stored, in separate overflow buckets to be processed
by another thread.
14. The database system of claim 8, wherein an input queue is
provided for each partition, enabling a thread processing of a
preceding partition to add overflow data to a subsequent input
queue.
15. A computer program product for lock-free creation of
partitioned hash tables in parallel, the computer program product
comprising a computer readable storage medium having program code
embodied therewith, the program code executable by a processor to:
partition a hash table of a database system; assign a separate
thread to each partition of the hash table; and execute a number of
the separate threads in parallel with other threads without a lock,
the executing for each of said number: scanning an input data table
for a thread's partition and applying a hash function to each key;
inserting data of keys that hash to the thread's partition into the
thread's partition; and ignoring keys that do not hash to the
thread's partition.
16. The computer program product of claim 15, wherein the scanning
of the input data table results in strictly sequential memory
accesses.
17. The computer program product of claim 15, wherein contents of
the thread's partition are flushed to main memory in response to
completing the executed thread.
Description
BACKGROUND
[0001] The present invention relates to creating hash tables, and
more specifically, to creating lock-free hash tables in
parallel.
[0002] The performance of many database queries, and in particular
more complex ones that require combining results from multiple
tables, typically depends on the efficiency of the relational join
operator. For queries referencing more than a few rows, an
efficient join method is a hash join. Each value of the join column
is hashed by a hash function to a value that indexes a bucket
(entry) in the hash table. A typical hash join first builds hash
tables for one or more smaller tables, usually smaller tables whose
contents more readily fit into memory, against which it then probes
the rows of the larger table using a different equality join
predicate for each table probed. If the join predicate is true, the
qualifying rows are added to a result set. The hash function may
introduce collisions, in which two distinct values of the same join
column may hash to the same bucket of the hash table.
[0003] Commodity, multi-core systems typically parallelize the
creation and probing of hash tables in an effort to improve join
performance. Probing an in-memory hash table in parallel does not
require any locking or latching, as it requires read-only access.
However, building a hash table in parallel typically results in
concurrent write access to the hash table, which requires a lock
for synchronization. Locking a memory region for exclusive access
is a time-consuming operation, particularly in the presence of
concurrent access to the same region by other insert operations
that have to wait for write access.
SUMMARY
[0004] According to an embodiment, a method, database system and
computer program product are provided for creating a hash table in
parallel without requiring a lock or random accesses to memory. The
hash table of a database system is partitioned and a separate
thread is assigned to each partition of the hash table. A number of
separate threads execute in parallel with other threads without a
lock. The execution of a number of separate threads includes:
scanning an input data table for a thread's partition and applying
a hash function to each key, inserting data of keys that hash to
the thread's partition into the thread's partition, and ignoring
keys that do not hash to the thread's partition.
[0005] Additional features and advantages are realized through the
techniques of the present invention. Other embodiments and aspects
of the invention are described in detail herein and are considered
a part of the claimed invention. For a better understanding of the
invention with the advantages and the features, refer to the
description and to the drawings.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
[0006] The subject matter which is regarded as the invention is
particularly pointed out and distinctly claimed in the claims at
the conclusion of the specification. The forgoing and other
features, and advantages of the invention are apparent from the
following detailed description taken in conjunction with the
accompanying drawings in which:
[0007] FIG. 1 depicts a diagrammatic representation of the creation
of a hash table in parallel according to the contemporary art;
[0008] FIG. 2 depicts a diagrammatic representation of the creation
of a hash table in parallel according to the contemporary art;
[0009] FIG. 3 depicts a flow chart of a lock-free creation of a
hash table in parallel according to an embodiment; and
[0010] FIG. 4 depicts a diagrammatic representation of a lock-free
creation of a hash table in parallel according to an
embodiment.
DETAILED DESCRIPTION
[0011] Embodiments disclosed herein drive hashing from the
perspective of a hash table and not from an input table.
Particularly, embodiments partition the hash table instead of
partitioning the input table. The input table is sequentially
scanned once for each hash table partition in parallel using a
separate thread for each hash table partition. Accordingly,
exemplary embodiments execute each separate thread in parallel for
each hash table partition without requiring a lock or random
accesses to memory.
[0012] Referring now to FIG. 1, a block diagram of a computer
system 10 suitable for creating lock-free hash tables in parallel
according to exemplary embodiments is shown. Computer system 10 is
only one example of a computer system and is not intended to
suggest any limitation as to the scope of use or functionality of
embodiments described herein. Regardless, computer system 10 is
capable of being implemented and/or performing any of the
functionality set forth hereinabove.
[0013] Computer system 10 is operational with numerous other
general purpose or special purpose computing system environments or
configurations. Examples of well-known computing systems,
environments, and/or configurations that may be suitable for use
with computer system 10 include, but are not limited to, personal
computer systems, server computer systems, thin clients, thick
clients, cellular telephones, handheld or laptop devices,
multiprocessor systems, microprocessor-based systems, set top
boxes, programmable consumer electronics, network PCs, minicomputer
systems, mainframe computer systems, and distributed cloud
computing environments that include any of the above systems or
devices, and the like. Special-purpose computer systems include
hardware accelerators such as FPGAs (Field-Programmable Gate
Arrays), GPUs (Graphics Processing Units), and similar systems,
which may be used in lieu of or in addition to general-purpose
processors.
[0014] Computer system 10 may be described in the general context
of computer system-executable instructions, such as program
modules, being executed by the computer system 10. Generally,
program modules may include routines, programs, objects,
components, logic, data structures, and so on that perform
particular tasks or implement particular abstract data types.
Computer system 10 may be practiced in distributed cloud computing
environments where tasks are performed by remote processing devices
that are linked through a communications network. In a distributed
computing environment, program modules may be located in both local
and remote computer system storage media including memory storage
devices.
[0015] As shown in FIG. 1, computer system 10 is shown in the form
of a general-purpose computing device, also referred to as a
processing device. The components of computer system may include,
but are not limited to, one or more processors or processing units
16, a system memory 28, and a bus 18 that couples various system
components including system memory 28 to processor 16. Computer
system 10 includes a chipset 12 to manage the data flow between the
processor 16, memory 28 and external devices 14.
[0016] Bus 18 represents one or more of any of several types of bus
structures, including a memory bus or memory controller, a
peripheral bus, an accelerated graphics port, and a processor or
local bus using any of a variety of bus architectures. By way of
example, and not limitation, such architectures include Industry
Standard Architecture (ISA) bus, Micro Channel Architecture (MCA)
bus, Enhanced ISA (EISA) bus, Video Electronics Standards
Association (VESA) local bus, and Peripheral Component
Interconnects (PCI) bus.
[0017] Computer system 10 may include a variety of computer system
readable media. Such media may be any available media that is
accessible by computer system/server 10, and it includes both
volatile and non-volatile media, removable and non-removable
media.
[0018] System memory 28 can include computer system readable media
in the form of volatile memory, such as random access memory (RAM).
Computer system may also include cache memory 32. Computer system
10 may further include other removable/non-removable,
volatile/non-volatile computer system storage media. By way of
example only, storage system 34 can be provided for reading from
and writing to a non-removable, non-volatile magnetic media (not
shown and typically called a "hard drive"). Although not shown, a
magnetic disk drive for reading from and writing to a removable,
non-volatile magnetic disk (e.g., a "floppy disk"), and an optical
disk drive for reading from or writing to a removable, non-volatile
optical disk such as a CD-ROM, DVD-ROM or other optical media can
be provided. In such instances, each can be connected to bus 18 by
one or more data media interfaces. As will be further depicted and
described below, memory 28 may include at least one program product
having a set (e.g., at least one) of program modules that are
configured to carry out the functions of embodiments of the
disclosure.
[0019] Computer system 10 may also communicate with one or more
external devices 14 such as a keyboard, a pointing device, a
display 24, etc.; one or more devices that enable a user to
interact with computer system/server 10; and/or any devices (e.g.,
network card, modem, etc.) that enable computer system/server 10 to
communicate with one or more other computing devices. Such
communication can occur via Input/Output (I/O) interfaces 22. Still
yet, computer system 10 can communicate with one or more networks
such as a local area network (LAN), a general wide area network
(WAN), and/or a public network (e.g., the Internet) via network
adapter 20. As depicted, network adapter 20 communicates with the
other components of computer system 10 via bus 18. It should be
understood that although not shown, other hardware and/or software
components could be used in conjunction with computer system 10.
Examples include, but are not limited to: microcode, device
drivers, redundant processing units, external disk drive arrays,
RAID systems, tape drives, and data archival storage systems,
etc.
[0020] In contemporary disk-based systems, input data tables that
do not fit in memory (RAM) are partitioned to minimize the number
of times that data are accessed and to perform mostly sequential
reads and writes to disk, because multiple scans of the input data
and/or random accesses to the data stored on disk are cost
prohibitive. However, even when the sequential bandwidth of an
individual disk reaches approximately 200 MB/s, the bandwidth is
reduced by orders of magnitude because access in parallel by
multiple processes usually requires random accesses that move the
disk arm when switching processes.
[0021] The growth of main memory capacities has made
main-memory-resident database systems more cost-effective.
Contemporary main-memory database systems help alleviate disk-based
input/output (I/O) bottlenecks, but run into other bottlenecks.
Even when all the requisite information for performing a hash join
is already in memory, hash table building and probing, which both
require random memory accesses, are the slowest and most costly
operations. Random memory accesses cause cache and, if used,
translation look-aside buffer (TLB) misses, which on contemporary
processors incur latencies of up to 300 and 1000 compute cycles,
respectively. Data stored in main memory can be accessed by
parallel processes and/or threads simultaneously. In fact, memory
bandwidth of contemporary multi-core architectures may peak at
nearly 200 GB/s when accessed via parallel scans. Probing an
in-memory hash table in parallel does not require any locking or
latching, as it requires read-only access. However, building a hash
table in parallel using the present state of the art results in
concurrent write access to the hash table, which requires some form
of synchronization.
[0022] FIG. 2 depicts a diagrammatic representation of the creation
of a hash table 210 in parallel according to the contemporary art.
As shown in FIG. 2, each partition--e.g., rows 221-223, 224-226,
227-229--of input table 220 is scanned in parallel and tuples are
randomly inserted into the hash table 210. The location of the
insert position is based on a hash value computed from the input
tuple, specifically its primary key. Exclusive access to a location
in the hash table 210 where a tuple is inserted is typically
enforced by a latch or lock synchronization mechanism to prevent
simultaneous updates to the same hash bucket by different threads
230, 240, 250 as shown in FIG. 2, that cause results written by one
thread to be erroneously overwritten by the other. Locking a memory
region of the hash table 210 for exclusive access is a
time-consuming operation, particularly in the presence of
concurrent access to the same region by other insert operations
that have to wait for write access.
[0023] One method for minimizing locking while creating a hash
table in parallel relies on partitioning the input data and having
each parallel process build a separate "local" hash table for its
individual partition. However, locking is eventually required to
combine these individual hash tables, unless each probe is executed
against all local hash tables. For hash tables that fit into the
processor cache, this might be a viable alternative, but otherwise
the cost of repeated random memory accesses will outweigh the cost
of synchronization required to create a single hash table.
[0024] Another method for minimizing locking while creating a hash
table in parallel relies on partitioning both input tables to a
join, such that each sub-table only needs to be joined with one
other sub-table without requiring a cross product of all
sub-tables. Because the data are already in memory, the tables are
partitioned based upon their hash prefix. This allows the actual
join to be executed in parallel without any further synchronization
because the hash tables are created per sub-table, and probing is
limited to sub-tables that share the same hash prefix. As a result
no locking is required, even when inserting data in parallel into
sub-tables.
[0025] However, this method requires two scans of each table or
intermediate result to be joined, one scan for partitioning the
rows and one scan for the actual join. The size of a sub-table is
usually chosen such that it fits into the processor cache to speed
up subsequent operations. Given the relatively small size of
processor caches, large input tables produce a significant number
of sub-tables. This in turn results in many distinct memory
references, which cause cache and TLB misses during partitioning.
Multi-phase partitioning may help to limit the number of distinct
memory references, but requires additional scans of the input data.
Even though this method yields an acceptable hash join performance,
its partitioning phase is a bottleneck. During the partitioning
phase, this method still requires some locking, and random memory
accesses cannot be avoided. Locking is required when aggregating
histograms, and using hash prefixes to partition a data set results
in random memory accesses while moving data to target locations
computed by the hash prefix. Moreover, with growing input table
size, this method requires multiple partitioning passes, each of
which requires scanning all input data and writing them to new,
random locations.
[0026] With reference to FIGS. 3 and 4, an embodiment for creating
a lock-free, hash table 410 in parallel is shown. The processing
unit 16 of FIG. 1 drives hashing and creation of a hash table 410
from the perspective of a hash table and not from an input data
table 420 according to an embodiment. In other words, an embodiment
makes the hash table 410 an active object in the creation of the
hash table 410, instead of a passive one as in previous
approaches.
[0027] In block 310, a hash table 410 is partitioned such that each
hash table partition 430, 440, 450 fits into a processor cache
according to an embodiment. A hash table partition size that fits
into the processor's cache minimizes main memory accesses during
hash table creation. In block 320, a separate thread is assigned to
each partition 430, 440, 450 of the hash table 410. Accordingly,
only the single thread assigned to a particular hash table
partition can write to or modify hash buckets within that
particular hash table partition. As a result, a thread can progress
independently of other threads without any need for
synchronization.
[0028] In block 330, each separate thread executes in parallel to
create its partition of the hash table 410. In an embodiment, the
execution of a thread includes scanning each row 421, 422, 423,
424, 425, 426, 427, 428, 429 of the input table 420 and applying
the hash function to each key as shown in block 340. If the hash
result falls into that thread's hash partition, the key-data pair
(e.g., a row, a row ID, or any value associated with the key) is
inserted into the hash partition assigned to the thread as shown in
block 350. For example, the hash result of input table rows
421,423, 425, 427 fall into hash table partition 430, the hash
result of input table rows 422, 428, 429 fall into hash table
partition 440, and the hash result of input table rows 424, 426
falls into hash table partition 450, as shown in detail in FIG.
4.
[0029] The input table 420 is scanned once for each hash table
partition in parallel. This embodiment requires scanning the input
table 420 as many times as there are hash table partitions 430,
440, 450. However, because the scanning can be done in parallel by
multiple threads, no requirement to lock for synchronization or to
access memory via random accesses will be necessary.
[0030] In block 360, embodiments simply ignore and bypass rows
which contain keys that do not hash to a particular thread's
assigned hash partition, because another thread assigned to another
hash partition of the hash table 410 will take care of inserting
those keys. Paying the cost of multiple passes over the input data
table 420 avoids locking the entire hash table 410 or a row of the
hash table for inserts, as only one thread is responsible for each
hash table partition 430, 440, 450.
[0031] There are multiple reasons why scanning the input data table
420 over and over is advantageous. First, sequential or streaming
access to data stored in main memory or in secondary storage is
known to be significantly faster than random access by more than an
order of magnitude. Second, in multi-core architectures, a single
thread cannot saturate memory bandwidth. Multiple threads are
necessary to achieve optimal memory performance. Third, scans can
be shared by multiple threads according to an embodiment. Once the
thread has completed its scan of the input data table 420,
addresses of that thread's hash table partition will no longer be
referenced and can be flushed to main memory. It should be noted
that the total number of threads that are active concurrently can
be significantly lower than the number of hash table
partitions.
[0032] Performance is governed by how fast the input table can be
scanned by each thread, and how fast the hash table partitions can
be flushed or written back to main memory. The resulting memory
access patterns and parallel sequential reads and writes may be
optimal for modern processors.
[0033] Accordingly, each thread can be executed independently and
requires no synchronization with other tasks according to disclosed
embodiments herein. Moreover, the scanning of input data results in
strictly sequential memory accesses, and choosing a partition size
less than or equal to the processor cache avoids cache and TLB
misses for inserting tuples into the appropriate hash table
partition.
[0034] The disclosed embodiments herein employ "embarrassingly
parallel" computing in that there is no dependency or
synchronization between parallel threads, and as such, embodiments
are well matched to multi-core architectures. Modern processor
architectures require parallel memory access from all cores in
order to achieve maximum memory performance. As there is no
synchronization required between threads in the embodiments
disclosed, all threads will be active continuously, as many as
required to saturate memory bandwidth of the target
architecture.
[0035] Hashing is known to raise the problem of collisions, in
which more than one distinct key hashes to the same location in the
hash table. Embodiments provide resolution protocols to collisions
via chaining and open addressing. Chaining generates an overflow
bucket to store the additional colliding key, and links it to all
other colliding keys for that hash bucket. On the other hand, open
addressing looks sequentially for the next available slot in the
hash table.
[0036] For both chaining and open addressing, a correct partition
size is selected to avoid random memory access due to cache and/or
TLB misses. Moreover, implementing chaining requires careful
engineering to avoid an excessive number of distinct memory
references that can cause cache and TLB misses. Open addressing
needs to address the case when there are no remaining slots in a
partition. For example, to demonstrate the effects of partition
size, consider a processor with 64 TLB entries and an operating
system with 4 KB memory pages. In this case, only memory addresses
within 64 distinct 4 KB pages can be accessed before encountering
TLB misses. On contemporary processors, this is more likely to be
the limiting factor than their several megabytes of cache.
[0037] Chained hashing grows the partition size in the presence of
collisions. Therefore, the partition size must be limited to the 64
buckets (i.e., the number of TLB entries), each with a maximum size
of 4 KB, which is equal to the page size. To avoid the cache and
TLB misses that are caused by following the pointers formed by the
chained buckets, an embodiment creates an index for currently
active buckets, that is, buckets that have space. As a result, full
buckets or pages are no longer referenced and will get flushed to
main memory automatically over time.
[0038] For open addressing, the size of each hash table partition
should not exceed 256 KB, which is the number of TLB entries times
the page size, to limit the cost of potentially scanning the entire
partition to locate an unoccupied slot in case of a collision.
[0039] For open addressing, a problem may arise when a collision
occurs and the search for a free slot reaches the end of a
partition. Simply continuing the search at the beginning of the
partition requires storing each partition boundary and probing the
hash table in exactly the same way and not allowing for linear
scans for matching keys. Moreover, this does not cover the case
when a partition is completely full. Inserting data directly into
the next partition requires coordination with the task handling
that partition (i.e., locking).
[0040] Accordingly, an embodiment stores data in separate overflow
buckets that are processed after a thread has finished scanning the
input table. In other words, data that does not fit into a
particular hash table partition is passed to another thread with an
overflow bucket. Another embodiment provides an input queue for
each hash table partition, to which the task processing the
preceding partition can add overflow data using an atomic add.
[0041] Technical effects and benefits of the disclosed embodiments
include improved performance for the creation of hash tables by
eliminating any requirement to lock for synchronization or to
access memory via random accesses (e.g., cache and TLB misses).
[0042] As will be appreciated by one skilled in the art, aspects of
the present invention may be embodied as a system, method or
computer program product. Accordingly, aspects of the present
invention may take the form of an entirely hardware embodiment, an
entirely software embodiment (including firmware, resident
software, micro-code, etc.) or an embodiment combining software and
hardware aspects that may all generally be referred to herein as a
"circuit," "module" or "system." Furthermore, aspects of the
present invention may take the form of a computer program product
embodied in one or more computer readable medium(s) having computer
readable program code embodied thereon.
[0043] Any combination of one or more computer readable medium(s)
may be utilized. The computer readable medium may be a computer
readable signal medium or a computer readable storage medium. A
computer readable storage medium may be, for example, but not
limited to, an electronic, magnetic, optical, electromagnetic,
infrared, or semiconductor system, apparatus, or device, or any
suitable combination of the foregoing. More specific examples (a
non-exhaustive list) of the computer readable storage medium would
include the following: an electrical connection having one or more
wires, a portable computer diskette, a hard disk, a random access
memory (RAM), a read-only memory (ROM), an erasable programmable
read-only memory (EPROM or Flash memory), an optical fiber, a
portable compact disc read-only memory (CD-ROM), an optical storage
device, a magnetic storage device, or any suitable combination of
the foregoing. In the context of this document, a computer readable
storage medium may be any tangible medium that can contain, or
store a program for use by or in connection with an instruction
execution system, apparatus, or device.
[0044] A computer readable signal medium may include a propagated
data signal with computer readable program code embodied therein,
for example, in baseband or as part of a carrier wave. Such a
propagated signal may take any of a variety of forms, including,
but not limited to, electro-magnetic, optical, or any suitable
combination thereof. A computer readable signal medium may be any
computer readable medium that is not a computer readable storage
medium and that can communicate, propagate, or transport a program
for use by or in connection with an instruction execution system,
apparatus, or device.
[0045] Program code embodied on a computer readable medium may be
transmitted using any appropriate medium, including but not limited
to wireless, wireline, optical fiber cable, RF, etc., or any
suitable combination of the foregoing.
[0046] Computer program code for carrying out operations for
aspects of the present invention may be written in any combination
of one or more programming languages, including an object oriented
programming language such as Java, Smalltalk, C++ or the like and
conventional procedural programming languages, such as the "C"
programming language or similar programming languages. The program
code may execute entirely on the user's computer, partly on the
user's computer, as a stand-alone software package, partly on the
user's computer and partly on a remote computer or entirely on the
remote computer or server. In the latter scenario, the remote
computer may be connected to the user's computer through any type
of network, including a local area network (LAN) or a wide area
network (WAN), or the connection may be made to an external
computer (for example, through the Internet using an Internet
Service Provider).
[0047] Aspects of the present invention are described above with
reference to flowchart illustrations and/or block diagrams of
methods, apparatus (systems) and computer program products
according to embodiments of the invention. It will be understood
that each block of the flowchart illustrations and/or block
diagrams, and combinations of blocks in the flowchart illustrations
and/or block diagrams, can be implemented by computer program
instructions. These computer program instructions may be provided
to a processor of a general purpose computer, special purpose
computer, or other programmable data processing apparatus to
produce a machine, such that the instructions, which execute via
the processor of the computer or other programmable data processing
apparatus, create means for implementing the functions/acts
specified in the flowchart and/or block diagram block or
blocks.
[0048] These computer program instructions may also be stored in a
computer readable medium that can direct a computer, other
programmable data processing apparatus, or other devices to
function in a particular manner, such that the instructions stored
in the computer readable medium produce an article of manufacture
including instructions which implement the function/act specified
in the flowchart and/or block diagram block or blocks.
[0049] The computer program instructions may also be loaded onto a
computer, other programmable data processing apparatus, or other
devices to cause a series of operational steps to be performed on
the computer, other programmable apparatus or other devices to
produce a computer implemented process such that the instructions
which execute on the computer or other programmable apparatus
provide processes for implementing the functions/acts specified in
the flowchart and/or block diagram block or blocks.
[0050] The disclosed flowchart and block diagrams illustrate the
architecture, functionality, and operation of possible
implementations of systems, methods and computer program products
according to various embodiments of the present invention. In this
regard, each block in the flowchart or block diagrams may represent
a module, segment, or portion of code, which comprises one or more
executable instructions for implementing the specified logical
function(s). It should also be noted that, in some alternative
implementations, the functions noted in the block may occur out of
the order noted in the figures. For example, two blocks shown in
succession may, in fact, be executed substantially concurrently, or
the blocks may sometimes be executed in the reverse order,
depending upon the functionality involved. It will also be noted
that each block of the block diagrams and/or flowchart
illustration, and combinations of blocks in the block diagrams
and/or flowchart illustration, can be implemented by special
purpose hardware-based systems that perform the specified functions
or acts, or combinations of special purpose hardware and computer
instructions.
[0051] The terminology used herein is for the purpose of describing
particular embodiments only and is not intended to be limiting of
the invention. As used herein, the singular forms "a", "an" and
"the" are intended to include the plural forms as well, unless the
context clearly indicates otherwise. It will be further understood
that the terms "comprises" and/or "comprising," when used in this
specification, specify the presence of stated features, integers,
steps, operations, elements, and/or components, but do not preclude
the presence or addition of one more other features, integers,
steps, operations, element components, and/or groups thereof.
[0052] The corresponding structures, materials, acts, and
equivalents of all means or step plus function elements in the
claims below are intended to include any structure, material, or
act for performing the function in combination with other claimed
elements as specifically claimed. The description of the present
invention has been presented for purposes of illustration and
description, but is not intended to be exhaustive or limited to the
invention in the form disclosed. Many modifications and variations
will be apparent to those of ordinary skill in the art without
departing from the scope and spirit of the invention. The
embodiment was chosen and described in order to best explain the
principles of the invention and the practical application, and to
enable others of ordinary skill in the art to understand the
invention for various embodiments with various modifications as are
suited to the particular use contemplated
[0053] The flow diagrams depicted herein are just one example.
There may be many variations to this diagram or the steps (or
operations) described therein without departing from the spirit of
the invention. For instance, the steps may be performed in a
differing order or steps may be added, deleted or modified. All of
these variations are considered a part of the claimed
invention.
[0054] While the preferred embodiment to the invention had been
described, it will be understood that those skilled in the art,
both now and in the future, may make various improvements and
enhancements which fall within the scope of the claims which
follow. These claims should be construed to maintain the proper
protection for the invention first described.
* * * * *