For anyone moving to this platform, the following from RD (via TDATA)
may solve some frustration with LOCKED clauses on READU's

We have a fix!

RD Tech Support have advised to add a string value 'UpdLockTimeout' to
D3Fsi reistry
to reduce the delay time when the second port reads the lock. The D3NT
7.5.0 default
is 3000 ms. Therefore:

- Shutdown the D3VME Service;
- Run > regedit
- open the path to:
HKey_Local_Machine\Software\RainingData\CurrentVer sion\D3FSI
and create a new> String Value: UpdLockTimeout
Value Data = 100

- Re-start the D3VME Service

I have tested this and find the LOCKED clause elapsed time results are
now at 0.015
seconds. A huge improvement from the 2.900 seconds yesterday.

An action item has been open to have this registry item added to the
7.5 admin
documentation.

Ross Ferris wrote:
Hi Ross

Does this mean that if the second port does a READU within 0.015 (or
2.9) seconds of the lock being taken then the LOCKED clause won't be
taken? So - you could have two ports that "think" they have the item
locked? Sorry if I've misconstrued.

Mike.

I'm not certain what this means. I have a laptop running 7.4.4

I lock an item and run the following program

open 'xx' else abort
time1 = system(9)
loop
readu rec from 'abc' locked crt 'locked @ ':time1 then
exit
end else exit
time1 = system(9)
repeat
crt 'unlocked @ ':time1
stop
end

I "unlock" the item on port 1 and the last two lines look like this:

locked @ 28010
unlocked @ 28090

So it looks like it only takes 10 milleseconds to recognize that a lock has
been released.

What was the original bug, and how does this fix effect us?

Mark Brown
"Mike Preece" <michael (AT) preece (DOT) net> wrote

Mark Brown wrote:
Hmm, when I ran that with a lock set, it went into a loop, just the way
the code is written. So I changed it to look like this...

open 'xx' else abort
time1 = system(12)
readu rec from 'abc' locked
crt 'Locked. Time taken ':system(12)-time1:'.'
end

Note that I used system(12) instead of system(9) - the millisecond
timer, not the CPU timer. The result was...

Locked. Time taken 0.

So, zero milliseconds, which sound about right. Though we know there is
some granularity to a PC clock, and that figure isn't exactly correct.
Still a long way from 2.9 seconds, though. Oh, and using system(9) gave
the same result - 0 ms.

Admittedly, I'm still on 7.4.0.NT.

Cheers,
Luke

The problem was that if PIB A had a lock on an FSI item, and PIB B
tried to do a READU, it was taking 3 seconds before the locked clause
was being activated - this "tweak" simply adjusts the amount of time
the process waits to see if it CAN get a lock, before taking the locked
clause


Luke Webber wrote:

Ross Ferris wrote:
Maybe I'm paraphrasing... Maybe I'm wrong... I guess there must be some
period, however small, between the time a process looks to see if a
lock is available and, if it's free, actually obtaining it. So - if
another process was to look during that time gap, it would see the lock
is free and also try to take it, and potentially overwrite/override the
previous setting. Is that why there must be a long enough delay - to
ensure this can't happen? And, if I'm on the right track, the delay
would have to be long enough to allow for the slowest disk access?

Mike.

Lock must be ATOM.
In other cases it is not lock.

Regards.

"Mike Preece" <michael (AT) preece (DOT) net> wrote

No, Mike, if this were true we'd all be out of business or be only in the
fix-the-database-errors business

There is always a *system internal lock*, with a test-and-set sequence which
must be atomic (i.e., a single uninterruptible instruction, it's not a
test, then set, in which case a second process can sneak in between). That
system internal lock, once set, ensures only that process can go on with
the code.At this point, it has, hopefully, exclusive control of the actual
group- or item-lock table and then can fiddle with it at will. At the end of
the lock manipulation, the system lock will be unset.

In PVA it used to be XCC (exchange characters instruction). But in our web
app, there is a queuing mechanism that has exactly the glitch Mike
mentionsIf anyone knows how to do this in javascript, I would be happy to
know it, I've so far ignored it because there has not been a
mission-critical reason to have it yet, especially with client speeds in the
gigahertz range (ie the gap is 1 javascript instruction time).

In BASIC terms, this is like saying:

READV LOCKBYTE FROM FILE, 'X', 1 THEN
IF LOCKBYTE = 0 THEN WRITE USERNO ON FILE,'X',1 ELSE NAP 100; [repeat]

where your program could be deactivated after it executes the Read and
before the Write, and another BASIC program, having done the same thing,
does the Write before you do, so both think it's ok.

Chandru Murthi

murthi wrote:
OK. Good. I'm happy about that. Thanks.

But... I was trying to figure out what the delay in activating the
LOCKED clause could be about. I'm now back where I started. A lock is
either set or it's not. Why wait? Why does it only (apparently) apply
to operations on FSI files? Why NT and not (apparently) *nix?

My JavaScript skills aren't quite as good as my PickBasic but I'd be
interested to see the actual code/function and see if I could figure
something out. I generally prefer to keep things simple on the client
and do all the real work in the DBMS in a real programming language -
rather than a scripting language. It is fun to play with JavaScript
though.

Mike.

"Mike Preece" <michael (AT) preece (DOT) net> wrote

Don't know answer to last two q'sm but for first, I'm pretty sure it's a
wait issue. Sort of like:
if ( recordlock is already set )
--wait for the specified time, during which try again from top
--at end of wait time... proceed with LOCKED clause code

this probably was meant to introduce a soft landing by repeating the lock
attempt more than once within the wait window. We do the same thing at the
application level by:

i = 1; foundit=1; gotit=0
loop
readu record from filevariable, itemid locked
i =1; nap 100
end then
gotit=1; exit
end else
gotit=1; record=''; foundit=0; exit
end
until i=10 do repeat ;* the wait time, in this case1 second = 100ms
* 10
if gotit else [locked record code]

So D3 has the same type of code *but at the system level*. The wait time was
3 seconds by default (clearly set by a somewhat overbearing systems
programmer, since it's not up the *system* to enforce this level of delay)
and can be reduced by the regedit.

Chandru Murthi


if (document.main.LOCK.value == "" ) //[1]
{ document.main.LOCK.value = 'MINE'; //[2]
... process whatever ....
document.main.LOCK.value = "" ; // release it for
others
} else {
// now the trick part, which I won't bore you with, since javascript
does
// not have any way to stall and try again...
}

The "gap" is between the test at [1] and the set at [2]. It is possible that
another javasscript thread can do exactly the same test at [1] and both
thread can continue at [2], the second one overstepping the first.

Chandru