Failing READU lock

#51

chandru murthi wrote:

Quote:

...Jim... I completely agree with you for once...

That "THUD" heard 'round the world was just
Frosty falling out of his chair. Please to
resume your normal progamming now! =`:^>

--
frosty

#52

Hi
Thanks for the answers Chandru & Mark. It seems that LOCK is exceptionally
efficient, I must consider it more often. I have always regarded READU as
gold, I am just concerned that maybe dual processors or some other
whizzbangs have broken something.
Peter McMurray
"Mark Brown" <mbrown (AT) drexelmgt (DOT) com> wrote

Quote:

"Excalibur" <excalibur21 (AT) bigpond (DOT) com> wrote in message
news:bbWZh.32537$M.13496 (AT) news-server (DOT) bigpond.net.au...
HI Mark
The fact that he has to do this must surely indicate that something is up
with READU. I have only ever used LOCK to stop two people doing the same
job at the same time eg Download a transaction file from a petrol pump.
I
would never consider doing it in this circumstance. My real concern is
that
the READU has never shown problems before and it is going to be a major
problem if it is broken.
Can you explain the difference in operation of the READ lock and the LOCK
lock and is there a major overhead in using the latter..
Thank You
Peter McMurray

Peter,

Basic Locks (System, Basic, Spooler):
There is a tally (2-bytes), normally initialized to xFF. When a process
attempts to set lock X, it positions itself to that field and checks the
contents. If it's xFF, it sets it to the value of the port setting the
lock. If it already has a value, THAT port holds the lock. Unlocking is
simply checking the tally and if it contains your port number, replace it
with xFF. There is no real "overhead" to using these locks. Basic locks
is how we got games to work. Set the lock, make your move, clear the
lock, wait for the lock to become available while the other player(s) make
turn(s).

Read Locks:
Read locks are different because there has to be a table of entries:
account, file, item, port holding the lock, and the PUSH level that port
is at. IIRC, they calculate some sort of hash 'token' and LOCATE it in
the table. And, I believe there's a separate lock table for FSI and VME,
because FSI can be accessed by "remote" users (distributed filesystem;
distributed processing, ODBC, etc). I believe there is a "system" lock on
the read-lock table, so it's actually a two-step process: Set the Table
Lock; Set/Release Read Lock; Release Table Lock.

D3/NT has the additional problem of allowing RPC connections. A remote
user can "open" a file, read and write records and close without ever
actually logging onto a system and so never really having a pib assigned.

Without actually seeing his code, I can't make judgements, but as someone
else posted, READU is as solid as anything. It's been around forever and
has been implemented on every Pick flavor in the world and has ALWAYS
worked. There has to be an answer, but it's not that READU is broken.

Mark Brown

#53

frosty wrote:

Quote:

chandru murthi wrote:
...Jim... I completely agree with you for once...

That "THUD" heard 'round the world was just
Frosty falling out of his chair. Please to
resume your normal progamming now! =`:^

Great minds think alike (every *Once* and awhile)

Patrick, <;=)

P.S I believe thats what makes them Great.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Failing READU lock

comp.databases.pick comp.databases.pick

Re: Failing READU lock - 05-02-2007 , 03:19 PM

Re: Failing READU lock - 05-02-2007 , 06:13 PM

Re: Failing READU lock - 05-02-2007 , 10:47 PM