Thanks for that longer explanation, but you can't avoid deadlocks with LOCKED 
clauses.
Maybe what you meant was something like "You can try to think of some strategy 
to deal with them when they occur."




-----Original Message-----
From: Charles Stevenson <[email protected]>
To: U2 Users List <[email protected]>
Sent: Tue, Oct 25, 2011 4:15 pm
Subject: Re: [U2] [UV] LIST.READU EVERY's "waiters" when there are writes w/o 
explicit 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 fail 
n 20 minutes?




 -----Original Message-----
 From: Charles Stevenson<[email protected]>
 To: U2 Users List<[email protected]>
 Sent: Tue, Oct 25, 2011 3:12 pm
 Subject: Re: [U2] [UV] LIST.READU EVERY's "waiters" when there are writes w/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.2.10 on Windows is behaving differently from what I recall.
   Are my expectations out of line?

   Suppose Session A holds a readu lock; and Session B attempts a WRITE
   to same record withOUT!!! 1st explicitly getting the readu lock.
   Session B waits for Session A to release the lock before writing the
   record.

   While Session B is waiting,  does it show up as a "waiter" in
   LIST.READU EVERY?
   I expected so,  but it doesn't.


   Session A                       Session B
   _____________________________   ___________________
   1A. ED VOC DUMMY
      (this sets the readu lock.)

   2A. (stay in editor)            2B. run this:
                                       01:    OPEN 'VOC' TO F ELSE STOPM
   'nope'
                                       02: ***READU REC FROM F, 'DUMMY'
   ELSE NULL
                                       03:    WRITE '' TO F, 'DUMMY'

   3A. Within ED:
       XEQ LIST.READU EVERY


   If I UN-comment line 2, LIST.READU EVERY shows something like this:

       Active Read Waiters:      Owner   Waiter
       Device....  Inode....     Userno  Userno
       746117947    232860913      6116    3396


   But when I comment out line 2, LIST.READU is silent.
   I have not yet explored what the deadlock daemon does.

   TIA,
   cds


   P.S. Yes, yes, "Bad Form", "Legacy Software", 20 min wait is
   configurable, . . . we can talk later.

 _______________________________________________
 2-Users mailing list
 [email protected]
 ttp://listserver.u2ug.org/mailman/listinfo/u2-users

 _______________________________________________
 U2-Users mailing list
 [email protected]
 http://listserver.u2ug.org/mailman/listinfo/u2-users

_______________________________________________
2-Users mailing list
[email protected]
ttp://listserver.u2ug.org/mailman/listinfo/u2-users

_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to