Image Threads Investigation Report

certain level in order to accommodate the multiple copies of the log record, trailer area
…etc.
¡
For every DBOPEN, one "accessor entry" and one DBU will be created. The address
of the DBU will be stored in "accessor entry" and the user count will be increased.
These three are tightly coupled to each other. If we share
DBU with threads, should we
share the "accessor entry" or create a new entry for each thread? Should the user
count match the number of DBUs or the number of threads? No
matter what choice we
make, the meaning will be changed.
3.2 Global variables
Compared to runtime control blocks, the issue of global variables is trivial. Global variables
reside in the SR5 virtual space. Because of the nature of forking a process versus creating a
thread, global variables might be shared by threads and should be copied for forked
processes.
3.3 Open files
Both thread and forked process share open files with their parent process. Because of that,
parent and child processes share the same pointers of those open files. Even though all the
data sets are files, TurboIMAGE, instead of using the current record pointer of the file system,
maintains the current record pointer internally for each data set opened and for every
DBOPEN. This is because the definition of "record" is different in the file system and in
TurboIMAGE. In the case of "serial read" or "chain read", TurboIMAGE figures out the next
record number to fetch, then calculates the offset in the data set file. After filling in the fields in
SMCB, TurboIMAGE calls the disk storage management routines to retrieve the data.
In DBU, TurboIMAGE has two tables: the User Local Data Set Table maintains the current
record pointers and backward/forward record pointers for each data set and the Data Set File
Table keeps the open file information for every data set. For the processes to share open files
actually means sharing those tables in DBU. It makes sense to share the SMCB so child
processes do not need to open the
data set again. However, I wonder how much benefit users
can get if TurboIMAGE allows sharing record pointers between processes.
4.
Feedback
Before I finalize this document, I sent out a preliminary investigation report to many experts in
the HP e3000 community asked for their feedback and opinions. Here is the summary of their
suggestions:
Even though to make TurboIMAGE thread aware and thread safe is the main topic, to allow
forking work with TurboIMAGE is also important. Several people think the fact, if a process
already have a database opened will cause fork() to fail, is a bug which we should fix.
Concurrency and performance are the essence of the thread. If we choose to share DBU and
DBUX by the threads; but for the integrity reason, we lock out each other to access the DBU
for the duration of processing the intrinsic or even whole transaction; that will be
unacceptable. In other words, we have to develop a sophisticated method to control the
access to DBU in the thread environment so that each thread can act like an independent
process and concurrently accessing the database.
If a thread programmer programs more than one thread to
access the same file, s/he is aware
that those threads are sharing the same record pointer. So, it is also the programmer’s
Page
8
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
...