Image Threads Investigation Report

categories: runtime control blocks, global variables and open files.
3.1 Runtime control blocks
There are two ways to handle the runtime control blocks: copy and share.
3.1.1 Copy DBU and DBUX
When a process, which already has an open TurboIMAGE
database, forks, one way to handle
the DBU and DBUX runtime control block is to copy. Copy all the DBUs and the DBUX, which
the parent process owned, to the SR5 virtual space of the forked process. The steps to
copying should be pretty similar to the steps in the DBOPEN, i.e. create DBUX, create DBU,
add DBU address into DBUX, increment the database open count, then add "accessor entry"
into DBG and link to DBU. The difference is, the copying step needs to create all the DBUs,
which the forking process have. Additionally, it should also copy the contents in the DBUs to
newly created DBUs because the forked process should inherit whatever the forking process
has. So, except for the transaction and locking related fields, the following items should all be
copied to the newly created DBUs: the current record pointers of each data set, open data set
files, current item lists for each data set as well as DBCONTROL settings. There are
advantages and disadvantages to this approach:
Pros:
¡
Current record pointers will not mess up. For example, the forking process reads down
a chain and then calls fork. If the forked process shares the DBU and does a DBFIND
to the same data set as the forking process, then the current record pointer will be
reset to the beginning of the chain and will cause the forking process to get a wrong
record for the next chain read. Copy DBU will avoid this kind of problem.
¡
Several fields in DBU are used to store the current XM status and transaction ID.
Some other fields are used for the locking status and for pointing to locks, which the
process owned. Separating the DBU can clearly distinguish
who owns what. Better yet,
each thread or process can have its own locks or transaction at the same time.
¡
For each DBOPEN, TurboIMAGE increases the user count in the root file as well as in
DBG. TurboIMAGE also creates an "accessor entry" in DBG with the owner PIN and
the address of the DBU, which is created by this DBOPEN. Copy DBU(s) then create
"accessor entry" for each DBU. This is a straightforward thing to do while forking.
¡
Each DBU has a trailer area, which is a scratch space for each TurboIMAGE intrinsic
to process intermediary data. For example, the space is used for converting a data set
name to a data set number, processing an item list
array or constructing a full record of
data if the user only passed in a partial record. If each process has its own DBU, then
we do not need to develop a complex trailer-area management procedure.
¡
The process termination procedure involves releasing all the locks the process still
owns, purging DBU and decreasing the open count from DBG and the root file. If each
thread or process has its own DBU, DBUX and "accessor entry", then the process
termination steps will be the same as usual. Otherwise, DBU/DBUX needs to keep
track of the number of processes accessing the control block and it needs to act
accordingly.
Cons:
¡
The effort to duplicate DBU(s) will be similar to a lightweight DBOPEN. Since the
DBOPEN intrinsic already has been criticized as a single threaded, time-consuming
Page
6
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
...