| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1632.1 | Locks are recommended when accessing a MIR | NANOVX::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Thu Oct 10 1991 10:00 | 18 |
| >> Is it recommended to always use a lock for read and writes from the
>> MIR, or is this just an example?
Both
Accessing a MIR should be controlled by Locks because creating anything
in a MIR requires two steps; Create the Instance, and Create the Attributes.
It is possible that two threads (on a single system, or across processes
in a Cluster) could try to create or delete the same instance record
in a MIR. Locks will ensure atomic operations on the MIR.
The Example FM was designed to demonstrate a lot of different DECmcc
functionality, as such a user-friendly layer was built on top of the
existing MIR routines. These routines make accessing the MIR simple
(I hope!), and elimintate a lot of programming steps (as you will see
from the MCC_EXAMPLE_FM_LIBRARY.C file).
/keith
|
| 1632.2 | MIR and locks | TOOK::CALLANDER | MCC = My Constant Companion | Wed Oct 23 1991 20:13 | 7 |
| One more thing to keep in mind about locking MIRs is how you are using them.
There are FM's that use the instance and attr MIRs more independently then
Keiths example. There are cases where exclusive locks may only be required
on deletes, since multiple writes are agreeable, as long as the code handles
the alreadyexists message coming back if some one else beats you in.
jill
|
| 1632.3 | locks are best | NANOVX::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Thu Oct 24 1991 07:56 | 17 |
| >> There are FM's that use the instance and attr MIRs more independently
>> then Keiths example.
>> There are cases where exclusive locks may only be required
>> on deletes, since multiple writes are agreeable, as long as the code
>> handles the alreadyexists message coming back if some one else beats
>> you in.
But if two threads try to create the same instance in a MIR, but
the attribute data is different - there is a problem. Without locks,
you'd thread 2 would accept the fact that the instance already exists,
then attempt to write the attributes - what about thread 1 ??
Locks are best used in this case, and with the new MIR interface demonstrated
in the Example FM -- no one needs to even think about them !! Just like RMS
locks records, but you don't need to do anything extra in your code 8)
/keith
|