Votes - 0, Average rating: 0
(
)
)
|
Other manuals for this model:
manual abstract
Image Threads Investigation Report
Page 4 of 9
are a few global variables exist, since they have to last and keep the value from one intrinsic
call to another intrinsic call. Those variables are created by TurboIMAGE and allocated in the
DP area in the SR5 virtual space. These variables are:
¡ qlock_trace: used to store debugging and tracing flags set by the user
¡ bti_globals: b-tree related flags, the timestamp… etc
¡ ccu_globals: jumbo data set related flags, attach/detach plabels, the timestamp …etc
¡ chunk_ctl: one object for every jumbo data set opened by the process, which contains
file related information (chunk data files) such as file ids, file SMCBs, open options and
the error status
These global variables should be taken care of in the thread environment.
2.1.3 Open files
A thread inherits the file structures of its initial thread; in other words, both threads share the
same open files. Thread programmers can call wrapped functions instead of normal intrinsics
in order to allow the file system to protect the data structures from multithreaded access. For
example, the thread program may call thd_fopen instead of fopen to open a file. That should
work fine for thread calling file system intrinsics, but how about TurboIMAGE database
access?
A database is a collection of files; database access actually ends up with file access.
However, only the root file is accessed by TurboIMAGE using file system intrinsics. For the
user data, TurboIMAGE uses lower level operating system procedures i.e. disc storage
management routines, to handle the reading and writing of data. Disc storage management
routines then call transaction management (XM) routines to ensure the physical and/or logical
data integrity. Sharing opened files means sharing the SMCBs (Storage Management Control
Block), so TurboIMAGE must introduce a mutex-like locking mechanism to lock out other
threads from accessing the same SMCB if one thread is reading or writing the same file.
2.2 Forked processes
In addition to thread, forking is also a new feature, which was introduced while MPE moved
toward open systems. A forked process inherits many characteristics from its parent process,
including open files. A forked process has its own data structures such as PIB, PIBX, PBC
and PBCX as well as its own SR5 virtual space. However, if a process already opened one or
more databases while forking, the forking step will fail. That is because DBU and DBUX are
open files from the file system’s point of view, but DBU and DBUX are new, no-named and
privileged files that the file system does not currently handle. So, how can we make forking
work with TurboIMAGE? Again, let’s assess the problem according to the following three
points:
2.2.1 Runtime control blocks
DBU and DBUX are the main obstacles while forking. The file system duplicates many data
structures of open files for a forked process. So, is it that simple just to ask the file system also
to copy DBU and DBUX while forking? No. Just duplicating the open DBU and DBUX and
copying the content does not solve the problem, because the data inside the DBU/DBUX
includes many pointers. They include pointers to each other (DBU to DBUX and DBUX to
DBU), pointers to DBG and DBB, pointers to locked entries in DBG and pointers to data sets.
So, simply copying the data in DBU will result in meaningless data.
The state of the forking process is another thing has to be taken care of. The forking process
http://www.hp.com/cgi-bin/pf-new.cgi?IN=http://jazz.external.hp.com/papers/image-threa...
7/18/2008
...Other models in this manual:
Software - MPE/iX 6.5 Operating System (60.29 kb)
Software - MPE/iX 7.0 Operating System (60.29 kb)
Software - MPE/iX 7.5 Operating System (60.29 kb)