Your example fails.
You are deliberately returning the user back to the beginning of a program deep
in progress, or you are assuming we know in advance what locks might be set.
Both of these are bad devices and assumptions.
Are you really going to throw away your order entry clerk's last five minutes
of typing without so much as a "by your leave" ?
He is going to be very mad at you for that.
-----Original Message-----
From: Charles Stevenson <stevenson.c...@gmail.com>
To: U2 Users List <u2-users@listserver.u2ug.org>
Cc: Wjhonson <wjhon...@aol.com>
Sent: Tue, Oct 25, 2011 5:21 pm
Subject: Re: [U2] [UV] LIST.READU EVERY's "waiters" when there are writes w/o
explicit readu.
Properly programmed locked clauses are exactly the means by which one
lways avoids deadlocks.
can think of no example where that would not work, including your
arlier example.
As an example, I have added LOCKED clauses to the 2 pgms I listed below
12 & W21.
If you run the original versions and wait for both to get to the prompt
efore hitting<enter> to both, you can't help but always get a deadlock.
f you run the LOCKED-clause-enabled versions, you can never get a deadlock.
(Forget about the GOTOs. I wanted to keep it simple to read. You can
o the same with LOOP-REPEAT.)
>CT CDS.BP W12 W21
W12
001 CRT TIMEDATE(), 'W12'
002 OPEN 'CDSTMP' TO F ELSE STOP
003 RDUS: READU REC1 FROM F, 'W1' LOCKED
004 SLEEP 1 ; * wait a bit
005 GO RDUS
006 END ELSE NULL
007 INPUT DUM
008 CRT TIMEDATE():'...':
009 READU REC2 FROM F, 'W2' LOCKED
010 RELEASE F, 'W1'
011 SLEEP 1 ; * wait a bit
012 GO RDUS
013 END ELSE NULL
014 WRITE TIME() TO F, 'W2'
015 CRT TIMEDATE()
W21
001 CRT TIMEDATE(), 'W21'
002 OPEN 'CDSTMP' TO F ELSE STOP
003 RDUS: READU REC1 FROM F, 'W2' LOCKED
004 SLEEP 1 ; * wait a bit
005 GO RDUS
006 END ELSE NULL
007 INPUT DUM
008 CRT TIMEDATE():'...':
009 READU REC2 FROM F, 'W1' LOCKED
010 RELEASE F, 'W2'
011 SLEEP 1 ; * wait a bit
012 GO RDUS
013 END ELSE NULL
014 WRITE TIME() TO F, 'W2'
015 CRT TIMEDATE()
On 10/25/2011 6:34 PM, Wjhonson wrote:
Thanks for that longer explanation, but you can't avoid deadlocks with LOCKED
lauses.
Maybe what you meant was something like "You can try to think of some strategy
o deal with them when they occur."
-----Original Message-----
From: Charles Stevenson<stevenson.c...@gmail.com>
To: U2 Users List<u2-users@listserver.u2ug.org>
Sent: Tue, Oct 25, 2011 4:15 pm
Subject: Re: [U2] [UV] LIST.READU EVERY's "waiters" when there are writes w/o
xplicit readu.
English is my 1st language, but that doesn't mean I'm good at it.
et me try again.
1. If either (or both) of these have WRITEs without explicit readus
head of time:
- the deadlock daemon seems to recognize the deadlock.
- If said WRITE command cannot gain a lock within 20 minutes it will
rror out. (That is the default behavior, but configurable.)
- So after 20 minutes (one of) the program(s) waiting on such a write
ill error out allowing the other to get the lock and continue.
2. If both programs have READUs:
- the deadlock deamon sees the condition and kills one of them.
The solution for completely avoiding a deadlock is - as always - to
roperly deploy LOCKED clauses.
n 10/25/2011 5:29 PM, Wjhonson wrote:
I dont' quite follow that.
Are you stating that if there is no explicit READU that both processes will
omplete without the deadlock deamon?
But if there is explicit READUs in both processes, that one of them will
ail
n 20 minutes?
-----Original Message-----
From: Charles Stevenson<stevenson.c...@gmail.com>
To: U2 Users List<u2-users@listserver.u2ug.org>
Sent: Tue, Oct 25, 2011 3:12 pm
Subject: Re: [U2] [UV] LIST.READU EVERY's "waiters" when there are writes
/o
xplicit readu.
On 10/24/2011 4:11 PM, Charles Stevenson wrote:
--- [snip] ---
I have not yet explored what the deadlock daemon does.
Deadlock daemon ignores these WRITEs w/o explicit locking before hand.
ran these 2 pgms simultaneously so that they both tried to lock or
rite the lock that the other held.
an with lines 6/7 variously commented out or left in.
W12 W21
01: CRT TIMEDATE(), 'W12' | CRT TIMEDATE(), 'W21'
2: OPEN 'CDSTMP' TO F ELSE STOP | OPEN 'CDSTMP' TO F ELSE STOP
3: READU REC1 FROM F, 'W1' ELSE NULL | READU REC2 FROM F, 'W2' ELSE NULL
4: INPUT DUM | INPUT DUM
5: CRT TIMEDATE():'...': | CRT TIMEDATE():'...':
6: *** READU REC2 FROM F, W2 ELSE NULL | READU REC1 FROM F, 'W1' ELSE NULL
7: WRITE TIME() TO F, 'W2' | WRITE TIME() TO F, 'W1'
8: CRT TIMEDATE() | CRT TIMEDATE()
hey invariably entered a deadly embrace, both processes waiting on the
ther, but the deadlock daemon ignored it if there is no explicit readu.
Instead one of them aborted with a write failure in 20 minutes (the
efault, but configurable action), then the other then continued happily.
hope no one but I ever cares about this.
Moral of the story:
Explicitly lock before you update.
cds
n 10/24/2011 4:11 PM, Charles Stevenson wrote:
UV 10
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
