Manualshelf

Image Threads Investigation Report

ManualsBrandsHP ManualsSoftwareMPE/iX 7.0 Operating System
123456789
responsibility to keep track of current record pointers if more than one thread would access
the same data set in the same database.
Many design suggestions such as adding new intrinsics for thread operation to use;
implementing "internal MR" to prevent potential deadlock between two PINs (but in the same
"thread family"); creating "light-weight" DBU, which contains only things need to be separated
etc. are also mentioned in their feedback.
5.
Recommendation and estimation
Based on the above discussion, I believe "pass base ID between processes" is not as
important as the other two requests. It is too ambitious to conquer this generalized
enhancement, which manipulate the base ID between any two processes; it is also not clear
that the benefit to the customer would be. Despite the complexity and performance
issues, the
logical conclusion is "sharing for threads" and "copying for forked processes". Because
threads share the SR5 space, they could also share DBU/DBUX and global variables. And
because forked processes have their own SR5 spaces that make more sense to copy the
DBUX/DBU(s) and global variables from the forking process. The implementations will be
different for these two different approaches. Based on the resources we currently have, I do
not think we can address them both at the same time. To implement in stages would be the
right approach.
6.
Issues
There are also several issues lie in front us if we do decide to implement either or both of the
enhancements.
Right now the performance is already a big issue for
fork() on HP e3000, especially compared
with UNIX fork(). We can spend a lot of effort to make TurboIMAGE work with fork(), but if the
overall performance is not acceptable, it is in vain. Worse than that, the additional work for
opened database(s) to fork is not simple. First we need to check all the databases, which
have being opened by the forking process, to make sure it is in the right state to fork. Then
we
copy all the DBUs and DBUX the forking process has into the SR5 space of the forked
process. The third step is to initialize the fields in DBU/DBUX that is not suitable for
duplication. And the last step is to link/update the
database open information in the global data
structure. The whole procedure is similar to a "light-weight" dbopen, which is pretty time
consuming. So, the performance of the overall forking procedure may get worse then current.
» Return to original page
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 2008 Hewlett-Packard Development Company, L.P.
Page
9
of
9
Image Threads Investigation Report
7/18/2008
http://www.hp.com/cgi
-
bin/pf
-
-
threa
...