Image Threads Investigation Report

procedure, the performance of the forking will be bad if we choose to copy the DBU(s).
¡
Threads share the same SR5 virtual space. So, if the initial thread opens many
databases and then creates many threads, then there may be a space problem if we
copy DBU(s) for every thread.
¡
One general concept for thread and forked processes is that they inherit (share) the
resource of the parent process. For instance, threads share the open files; thus they
also share the current record pointers. So, conceptually, threads should share the
current record pointers for every data set. If TurboIMAGE copies DBU, that will break
the convention.
3.1.2 Share DBU and DBUX
Instead of copying DBU and DBUX, it makes more sense for thread to share DBU and DBUX.
However, since the DBU and DBUX are designed to be accessed only by one process,
sharing methods need to be added to handle the multi-accessing of a DBU. For example,
DBU used to be owned by a process, now an array of accessing PINs may be needed in the
DBU. We may also need several semaphores to control the write to many tables in DBU. The
trailer area needs to be divided into sub-areas. So, different threads can work on the same
DBU at the same time. If we do not divide it, one thread may lock out the other threads for the
whole duration of an intrinsic, then the concurrency will be an issue. Let’s also list the pros
and cons of this approach:
Pros:
¡
To share the resources with the initial thread is the key point for the thread
environment; especially all threads share the SR5 space. So, intuitively, all threads
should share DBU and DBUX.
¡
A table in DBU keeps all the open file information, that includes file id, file offset and
SMCB virtual address …etc. One entry exists for each open data set. Since threads
share the files, it is natural that they share this table in DBU.
¡
The user local data set table in DBU holds current record pointers for each data set.
Share DBU means sharing the record pointers for every data set. It is the convention
for files, but how about data sets? Which way make more sense to the user? Which
way can benefit users more?
Cons:
¡
All the transaction-related information is stored in DBU. In order to share the DBU
among threads, some kind of lock needs to be used to protect the on-going
transaction. User may or may not explicitly start a transaction. If the user does not
explicitly start a transaction, in order to maintain data integrity, TurboIMAGE will create
a transaction internally for each modification intrinsic. So, the duration of a transaction
can be as short as a TurboIMAGE intrinsic or as long as hundreds or thousands of
intrinsics. In other words, the duration to hold the lock can be too long to be practical.
The same concern also applies to those fields in DBU for process-owned
locks. Maybe
we should allocate different spaces for different threads.
¡
The DBU trailer area is another big concern when it is shared by threads. The trailer
area is continuously being used over the whole duration of processing an intrinsic. The
performance concern would lead us to design a more sophisticated space
management system instead of a single threaded mechanism.
¡
The log record buffer is located in the DBU. That is another big chunk of space that
can not be shared by threads. Apparently, the DBU size should be increased to a
Page
7
of
9
Image Threads Investigation Report
7/18/2008
http://www.hp.com/cgi
-
bin/pf
-
new.cgi?IN=http://jazz.external.hp.com/papers/image
-
threa
...