Point taken, but I didn't say anything about WANTing to do it that way.
This is existing software & I'm trying to what's important to fix first.

Because there is a sort of implicit behind-the-scenes wait-for-then-lock that happens on any WRITE to a record that is not explicitly (i.e., properly) readu'd 1st, I expected it to show up in the LIST.READU's "waiter" section. I was hoping to monitor that to triage how big a problem it is in practice.

By the way, WRITEU & DELETEU will NOT preserve that "implicit" lock; it only preserves an explicit lock that already exists.

Personally, I advocate a programming standard that insists on explicit READU (or RECORDLOCKU) before updates & deletes. TRANSACTIONs demand it.
Furthermore, there should always be LOCKED clauses.

On 10/24/2011 5:30 PM, Mecki Foerthmann wrote:
Now why would anybody want to use a WRITE without a READU?
I can possibly understand that somebody would want to do it with a WRITEV (i.e writing a flag on a record) but WRITE?
And WRITE totally ignoring locking would be outright stupid.

On 24/10/2011 22:28, Woodward, Bob wrote:
I would think that because you are not trying to obtain the lock in a
WRITE statement, it would not be classified as a waiter.  True, it's
waiting because of the lock but by not trying to obtain the lock, it's
only waiting for the blockage to clear.  If it were to be classified as
a waiter then I would expect to see a LOCKED clause on the WRITE
statement like there is on the READU.  For that matter, I'd expect to
see a WRITEU command as well and the standard WRITE to completely ignore

Just my guess, though.


-----Original Message-----
[] On Behalf Of Charles
Sent: Monday, October 24, 2011 2:12 PM
To: U2 Users List
Subject: [U2] [UV] LIST.READU EVERY's "waiters" when there are writes
w/o explicit readu.

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

While Session B is waiting,  does it show up as a "waiter" in LIST.READU

I expected so,  but it doesn't.

Session A                       Session B
_____________________________   ___________________
     (this sets the readu lock.)

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

3A. Within ED:

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.


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

U2-Users mailing list

Reply via email to