David,
Thank-you for your consideration.
I tried pursued both your suggestions, but:
1. I see the same behavior whether VOC DUMMY already exists or is a new
record.
That is consistent with how I understand the lock table to work. The
lock table is held in memory, shared by all UV users, and completely
separate from the files themselves. Whether or not a record exists is
neither here nor there to the lock table. (Incidentally, that makes
RECORDLOCKED() & RECORDLOCKU attractive commands when you can get away
with it. They don't actually go after the data on file, just the lock
table in memory.)
2. The ap in question doesn't use readL-locks, so it's purely academic,
but I tried variations on the theme below & itworks the same whether
readU- or readL-locks are used.
Session A: Instead of using ED VOC DUMMY to set a readU-lock, I use a
pgm to set & hold a readL-lock:
OPEN 'VOC' TO F ELSE STOPM 'NOPE'
READL REC FROM F, 'DUMMY' ELSE NULL
CRT TIMEDATE(), 'READLd':
INPUT X ; * <--- Dont <enter> until start session B's pgm
STOPM TIMEDATE()
Session B:
OPEN 'VOC' TO F ELSE STOPM 'NOPE'
***READ[U/L] REC FROM F, 'DUMMY' ELSE NULL
WRITE '' TO F, 'DUMMY'
still waits, but does not show up in LIST.READU EVERY waiter section.
I'd really be interested to see what you get if you have a non-windows
system to try it on, or an older version than UV10.2.
Thanks again,
cds
On 10/30/2011 6:10 PM, David Jordan wrote:
Hi Charles
Just a thought. When you ED VOC Dummy, you are creating a new record, where
you are locking the Key to not be used by another process rather than locking
the record. I am not sure where the locks are on the file system, but I
wonder if Dummy already existed before you edited, whether this would be
different. Also it would be worth test the difference of using READL and READU.
David
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Charles Stevenson
Sent: Sunday, 30 October 2011 10:22 AM
To: Charles Stevenson
Cc: U2 Users List
Subject: Re: [U2] [UV] LIST.READU EVERY's "waiters" when there are writes w/o
explicit readu.
I hate to bring it up after 50+ responses over 4 days, but . . .
Did anyone ever actually run my little test?
On something other than my UV10.2/Win? Unix? Before UV10.2?
Knowing that would help me assess the size& age of our problem.
I still think that in times past, a waiterfor a lockvia WRITE or DELETEwould
show up at the 3rd section of LIST.READU EVERY, even as the typical READU (or
FILELOCK, RECORDLOCKU) does.
The original test was request was this:
On 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 STOP
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.
"Later" is already past. I'm not talking about that P.S. again!
thank-you,
cds
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
