Image Threads Investigation Report

2.1.1 Runtime control blocks
For every DBOPEN user’s program called, a runtime control block named DBU will be
created. A DBU contains the information specific to this DBOPEN. This includes:
¡
transaction information (XMUI, GTX’id, 00-file…etc)
¡
locking information (data set and/or predicate level locks it owns, pointers to owned
locks…etc)
¡
logging information (transaction id, MDBX base ids, log buffer)
¡
current record pointers as well as back/forward record pointers for each data set
¡
open data set files and SMCB of those files
¡
current item lists for each data set
¡
critical level, system depth
¡
error handling
¡
dbcontrol settings for this OPEN
¡
fields for bookkeeping purpose (intrinsics count)
DBU also has a trailer area to be used as a temporary
data processing space. Each DBOPEN
has one DBU. If a process opens the same database twice or a process opens two
databases, then two DBUs will be created. A process can have maximum of 127 DBUs
created.
A DBUX runtime control block will be created when the process first opens a database. Only
one DBUX exists for each process and that contains:
¡
pointers to all DBUs which belongs to this process
¡
TPI/TPS Plabels
¡
lock table pointer
¡
GTX table pointer
¡
dynamic rollback record number mapping table for rollback activity
¡
process termination trigger
Both DBU and DBUX reside in SR5 virtual space. Since threads share the SR5 virtual space,
it is natural to think we should share the DBU and DBUX as well. However, both DBU and
DBUX are designed for not sharing between processes (in other words, shared by different
PINs). It is assumed that only the process, which creates the DBU and DBUX, will access it.
So there is no locking mechanism to protect the write to fields in DBU and DBUX from other
processes. And it is not safe (incorrect) to share the XM logging, data set and predicate level
locks. Current record pointers will be messed up if more than one thread updates the pointer
for the same data set. Critical level, intrinsic count and DBCONTROL settings may all
incorrectly reflect the real value and lead to data corruption or even a system abort.
There are other runtime control blocks been used during database access, such as DBG,
DBB and DBS. DBG and DBB are created when the first user opens a database. One DBG
and one DBB are created for each database opened and are shared by all the users on the
system. Only one DBS is created on a system and is also shared by all the users. All of them
are originally designed for sharing among the users, so they should be safe for thread
accessing. However, there are still a few things that need to be taken care of. For
example, an
"accessor entry" will be allocated in DBG for every DBOPEN. The entry is identified by a PIN
and the open count, and has a pointer pointing to the DBU that was created by this DBOPEN.
If more than one thread shares the DBU, should each thread have its own ‘accessor’ entry?
2.1.2 Global variables
TurboIMAGE is composed of a set of procedures called ‘intrinsics’. Since thread has it own
stack, procedure local variables, which are allocated when calling TurboIMAGE intrinsics and
deallocated when exiting the intrinsic, are
not problems in thread environment. However, there
Page
3
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
...