Dave wrote:

> Hope so, but someone else said it wouldn't work because of a deadlock
if 
> daddy
> kills off junior while junior is waiting for a lock.  I haven't seen 
> anyone
> else refute that, and I wouldn't claim to know.  We do only really
simple
> locking and I've never had to pay attention to deadlock rules.

Yes, that might be a problem.  Not a deadlock, per se, but I don't know
what happens if you try to kill a child process while it's waiting on an
unconditional lock request to be satisfied.

> Meanwhile, is this still at the prison system ?  Anyone else find it 
> ironic
> that they might have issues with locking strategy ? :)

You think that's bad?  Try programming in an environment where you're
not allowed to use "escape" sequences!

Walter  

----- Original Message ----- 
From: "Walter J. Murray" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Wednesday, May 28, 2008 21:26
Subject: Re: [HP3000-L] TurboIMAGE: Timed lock request


> Beautiful!
>
> Too bad junior can't give the lock to daddy.  ("I yield the lock to my
> father.")  Since it's junior who gets the lock, it has to be junior
who
> does the updates.  But I think this could be made to work.  Thank you
> Dave.
>
> Walter
>
>
> -----Original Message-----
> From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
> Behalf Of Dave Powell, MMfab
> Sent: Wednesday, May 28, 2008 12:26 PM
> To: [log in to unmask]
> Subject: Re: [HP3000-L] TurboIMAGE: Timed lock request
>
> I think he can do it with a whole lot of rewriting...
> 1: Separate off the (unconditional) lock & updates into a second
little
> program.
> 2: Have the main program create & activate the new child program as
> needed.
> 3: Have the child program notify daddy when the lock comes thru, by
> writing to
> a message file, or some such, BEFORE it starts any updates.
> 4: If daddy doesn't get the good news within 15 seconds, it kills off
> junior
> and tells the user to try again later.  (Maybe daddy did a 15-second
> timed
> read on the message file -- this way the wait and the mechanism to get
> the
> news are combined into one step).
> 5: To make it completely bulletproof even if the timing comes out
worst
> case,
> daddy may need to send some acknowlegement back to junior when it gets
> the
> good news about the lock, and junior needs to wait for that before
> starting
> the updates.
>
> I have no particular opinion on whether its worth all the re-writes,
but
> it
> ought to be possible.
>
>
> ----- Original Message ----- 
> From: "Denys Beauchemin" <[log in to unmask]>
> To: <[log in to unmask]>
> Sent: Tuesday, May 27, 2008 20:53
> Subject: Re: [HP3000-L] TurboIMAGE: Timed lock request
>
>
> > I just do not see a way in which this could be accomplished; in
order
> to
> > retain control, you have to use conditional locks and that never
gets
> you in
> > the queue.  If you use unconditional locking, you're toast.
> >
> > I would hunt down the offending programs and fix them.
> >
> > Denys...
> >
> > -----Original Message-----
> > From: Walter J. Murray [mailto:[log in to unmask]]
> > Sent: Tuesday, May 27, 2008 10:43 PM
> > To: 'Denys Beauchemin'; [log in to unmask]
> > Subject: RE: [HP3000-L] TurboIMAGE: Timed lock request
> >
> > The problem is that some of the programs don't "play by the rules,"
as
> > Denys puts it.  They lock around terminal reads.  If I do a regular
> > unconditional lock, which I would like to do, I run the risk of
> hanging
> > until the other user gets back from lunch.
> >
> > Yes, this is a real-world problem for me.  I would like to issue an
> > unconditional lock request (get queued up waiting for the request to
> be
> > satisfied), but be able to bail out if it's not satisfied within 15
> > seconds, and tell the user to try again later.
> >
> > No, I am definitely not looking for HP to implement this as an
> > enhancement--just wondering if it has ever come up.
> >
> > Yes, I meant to say I could issue a CONDITIONAL lock every second
for
> 15
> > seconds, but that wouldn't meet my needs.
> >
> > Walter
> >
> > -----Original Message-----
> > From: Denys Beauchemin [mailto:[log in to unmask]]
> > Sent: Monday, May 26, 2008 6:28 PM
> > To: 'Walter J. Murray'; [log in to unmask]
> > Subject: RE: [HP3000-L] TurboIMAGE: Timed lock request
> >
> > It looks like you're asking for something like a second conditional
in
> > English.  I'm not sure if it would be easy to implement in the first
> > place
> > and I can see where it may cause more harm than good.  A long time
> ago,
> > I
> > wrote an order entry application that started using conditional
locks.
> > I
> > quickly changed that to unconditional locks because users complained
> > about
> > having to issue a "yes" to retry the locks on many orders.  Granted,
> it
> > was
> > a silly idea but this was about 30 years ago.  I find that as long
as
> > your
> > programs play by the rules (no MR or strictly controlled MR and no
> locks
> > around terminal reads,) the application flows much faster using pure
> > unconditional locks.
> >
> > Did you have a specific application in mind for this?  Perhaps there
> may
> > be
> > another way to implement such a mechanism; I seriously doubt HP will
> > enhance
> > IMAGE to add this request.
> >
> > Also, I think you mean your process would issue a conditional lock
one
> a
> > second for 15 seconds and no, that will not do the trick, that was
the
> > problem I had 30 years ago.  (Has it really been 30 years? I guess
so.
> > Sigh.)
> >
> > Denys...
> > -----Original Message-----
> > From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
> > Behalf
> > Of Walter J. Murray
> > Sent: Monday, May 26, 2008 8:04 PM
> > To: [log in to unmask]
> > Subject: [HP3000-L] TurboIMAGE: Timed lock request
> >
> > Greetings,
> >
> > Time for another TurboIMAGE question.
> >
> > I'm pretty sure there is no way to do this directly in TurboIMAGE.
I
> am
> > curious whether it has ever been an enhancement request, or whether
> > someone has a suggestion of how to accomplish something equivalent.
> >
> > I want something that's like a cross between an unconditional and a
> > conditional lock request.  I'd like to issue a lock request using
this
> > new mode, and specifying a time interval, e.g., 15 seconds.
> >
> > If the lock can be granted immediately, fine.
> >
> > If not, the request is queued and my process is blocked, just as for
> an
> > unconditional lock request.
> >
> > If the lock can be granted within the specified interval, control
> > returns to my process, just as when an unconditional lock request is
> > granted.
> >
> > If the lock is still pending when the specified time has elapsed, my
> > request is deleted from the queue, and I get a status return
> indicating
> > that my request was unsuccessful because of a timeout.
> >
> > It would be like a timed read against a terminal or a message file.
> It
> > seems like something that would be very useful, but I don't remember
> > ever having heard it suggested.
> >
> > Without this feature, the best I know of to do is to issue an
> > unconditional lock request every second for 15 seconds, and then
give
> > up.  This is not a very good substitute for what I want, because my
> > request never gets queued up.
> >
> > Walter
> >
> > Walter J. Murray
> >
> > * To join/leave the list, search archives, change list settings, *
> > * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
> >
> > * To join/leave the list, search archives, change list settings, *
> > * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
> >
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *