On Sat, 4/1, Stan Sieler <[log in to unmask]> wrote:
 
> Jerry Fochtman ([log in to unmask]) wrote:
 
[...snip...]
 
>: I would recommend dropping this item from the SIGMPE list based upon:
>
>:   1)  I don't believe this is an MPE issue, but rather belongs to
>:       IMAGE/SQL.
 
> Actually, I think this is a definite MPE problem.  The deadly embraces
> are generally caused by code that waits on semaphores of one kind or
> another.  Within the operating system, this is generally a routine
> called "cb_lock" (or a variant).
 
> None of these routines have a timeout parameter.  I think that if
> semaphore locking had such parameters, and returned "failed" after that
> amount of time elapsed, we'd never again have a deadly embrace.
 
[...snip...]
 
> Additionally, *mandatory* use of such a parameter by the operating
> system would preclude deadlocks between any combination of
> things like: FLOCK, DBLOCK, GETSIR, cb_lock, OBTAIN.
 
> Yes, converting to this scheme would cause a bit of work for the lab :)
 
[...snip...]
 
> The real major chunk of work in many cases is adding appropriate error
> action to the source code of the operating system.
 
[...snip...]
 
> But, in many parts of the operating system there isn't such a path...
> because the authors (including me) of code that called cb_lock never
> expected it to fail...because it *couldn't* fail, by design.
 
> Anyway...this is a real MPE issue, not just a SIGImage issue.
 
 
I agree with Stan, that the root problem is in the deep, internal semaphore
management process and if solved there, would benefit other areas of the
O/S.  If this is the intent of this enh. request, then perhaps the title
should be changed to reflect this view.  Given the current title though,
I still feel that as stated, this enh. request is no longer currently needed
given the solution built into IMAGE/SQL.
 
Like you, I still have some low-level code (ported from MPE-V) which does
it's own 'OBTAIN/RELEASE' work and would agree with you, that by design,
I too would be facing some problems under certain conditions.
 
Perhaps it might be possible to also integrate into the low-level
routines a deadlock detection mechanism in addition to the timer?  I would
assume that a zero timer value would imply an indefinite wait which would
not preclude a badly designed process from still causing a deadlock(?).
Yet on the other hand I can appreciate your approach given that at this
level its ideal to setup the timer request.  Perhaps a combination would
be the most failsafe approach....
 
However, HP's MPE/iX folks as well as some users may be concerned
about the performance impact of the longer path to execute the semaphore lock
as opposed to the risk of deadlocks and what can be done at a higher level.
Do we know how often there are deadlocks that are not IMAGE-related?
(Tell us it ain't true Mike P! ;-> )
 
Oh well, here we are again...more trade-offs...
 
Thanks Stan, for expanding on the 'root-cause' issue!
 
-- Jerry