| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 58.1 | What Is The Application? | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Thu Jan 16 1997 13:06 | 30 |
| 58.2 | | EVMS::MORONEY | SYS$BOOM_BAH | Thu Jan 16 1997 14:18 | 5 |
| 58.3 | Crude, ugly and inefficient mechanism, but it might work | GIDDAY::GILLINGS | a crucible of informative mistakes | Thu Jan 16 1997 20:38 | 7 |
| 58.4 | | KERNEL::WILSONP | | Thu Jan 30 1997 08:30 | 22 |
| Sorry for the delay in replying, I have been on a training
course.
>Rather than discussing specifics of the lock manager implementation,
>please provide us with some specifics of the problem the customer is
>trying to solve here.
The requirement is to provide a cluster wide synchroning mechanism which
is available from DCL.
Of course if we had CWLNMs they could be used ;-}...
1/ To preventresource contention during startup the customer wants to
implement a lock facility to DCL. i.e
$ SYSLOCK LOCK FOO
$ dcl commands...
$ SYSLOCK UNLOCK FOO
2/ For cluster wide login synchronisation and validation
I don't think he would like anything that came from UNIX as he is a VMS
bigot:-(
Seriously, the problems with file locks is the cleanup and I/O overhead.
|
| 58.5 | do it in DCL | EVMS::KUEHNEL | Andy K�hnel | Thu Jan 30 1997 09:09 | 19 |
| I'd still suggest a file-based solution. There is hardly any I/O
overhead and you get automatic cleanup if the process dies, and it can
all be done very easily in DCL.
All you need is a file that's created just once on a cluster-wide
accessible volume. Then you can:
$lock_loop:
$ open/read/write/error=lock_wait lock disk$mumble:[000000]lock_file.dat
$ !
$ ! your protected DCL commands come here
$ !
$ close lock
$lock_wait:
$ wait 0:0:5
$ goto lock_loop
|
| 58.6 | Is .2 wrong | RTOAL2::MAHER | TIER3 simply a better RPC! | Thu Jan 30 1997 09:20 | 6 |
| Hi,
Is Mike in .2 wrong? It sounds good to me and if the process dies
before releasing the lock it will get blown away.
Regards Richard Maher.
|
| 58.7 | | EVMS::KUEHNEL | Andy K�hnel | Thu Jan 30 1997 14:31 | 8 |
| re .6
I'm not a locking specialist, but it strikes me that anything involving
an image activation can hardly involve less overhead than something
done just within DCL. .5 appears to solve the customer's problem and I
just don't believe in unnecessary kernel mode hacks.
-andy
|
| 58.8 | | EVMS::MORONEY | UHF Computers | Thu Jan 30 1997 15:19 | 7 |
| re .6:
I just verified that locks granted in exec or super mode do stick around
until process termination as expected. Regardless, I agree with .7, .5
is at least a supported solution, and allows a multiple-reader mode
($ OPEN/READ) and an exclusive mode ($ OPEN/READ/WRITE).
It also doesn't require privileges.
|
| 58.9 | You need to use the lock mgr if you really want synchronization. | WAYLAY::GORDON | Resident Lightning Designer | Thu Jan 30 1997 18:03 | 5 |
| Cluster-wide logical names would not provide appropriate
synchronization. This has been the subject of some discussion here in
engineering.
--Doug
|