Mumps locks question

[kdt...@gmail.com]

Hey all,

I don't have much experience with record locking. But I am writing
some code where it is needed.

Here is a code snipet.

. LOCK +^SC(TMGIEN) ;"LOCK HERE
. ELSE DO QUIT
. . SET TMGMSG(TMG1DATE_"^"_TMGLIMDT)="Unable to get lock on
^SC("_TMGIEN_")."
. . SET TMGRESULT=-1,TMGABORT=1
. NEW TEMP
. SET TEMP=$$ONEDAY(TMGIEN,TMG1DATE,TMGLIMDT,TEMPFLGS,$NAME
(TMGPATRN(TMGDTRNG)),.TMGMSG)
. LOCK -^SC(TMGIEN) ;"RELEASE LOCK...

When I step through this in my debugger, the LOCK command fails, i.e.
it sets the %T variable so that the ELSE path is followed.

Questions:
1. Who would be locking the ^SC( node. I am not using scheduling in
my system currently.
2. Is my syntax correct?
3. Is there a way to see who has a record locked?
4. does the SET command respect the LOCK status? I.e. If I can set
and manipulate the globals, then does that automatically mean that
they are not in a locked state? Because I can set these nodes. So
why can't I lock them?

Thanks
Kevin

[Gregory Woodhouse]

On Jan 6, 2009, at 4:26 PM, kdt...@gmail.com wrote:

> Questions:
> 1. Who would be locking the ^SC( node. I am not using scheduling in
> my system currently.

I have no idea.

>
> 2. Is my syntax correct?

It looks fine to me.

>
> 3. Is there a way to see who has a record locked?

It's system dependent. I don't know how it's done on GT.M

>
> 4. does the SET command respect the LOCK status? I.e. If I can set
> and manipulate the globals, then does that automatically mean that
> they are not in a locked state? Because I can set these nodes. So
> why can't I lock them?

Locks a purely advisory in MUMPS. I'd love to have mandatory locks,
but the language designers obviously thought differently.

[chuck5566]

Try using a time out on the lock set, something like .LOCK
+^SC(TMGIEN):1, maybe even .LOCK +^SC(TMGIEN):0

In fact, without the timeout, if "someone" else has already locked the
node, wouldn't this code just sit there until the node is unlocked?

[kdt...@gmail.com]

So are you saying that even if another process locks a node, then I
can still write to that node? So locking has no "teeth" so to speak?

So then have a working lock system depends on each process respecting
the lock system, i.e. checking with a lock command before writing?

Interesting...

Kevin

Gregory Woodhouse wrote:
...

[kdt...@gmail.com]

Good point. Thanks. I'll change the code.

Kevin

[K.S. Bhaskar]

MUMPS locks are like traffic lights and not like the locks on doors.  A car that has a green light has the right of way by tradition, but nothing other than custom stops the car with a red light from going through.  A lock on the door of course stops you from entering unless you have the key.

Cheers
-- Bhaskar

[Gregory Woodhouse]

On Jan 7, 2009, at 5:14 AM, kdt...@gmail.com wrote:

> Good point. Thanks. I'll change the code.
>
> Kevin
>
> On Jan 7, 12:10 am, chuck5566 <chuck5...@gmail.com> wrote:
>> Try using a time out on the lock set, something like .LOCK
>> +^SC(TMGIEN):1, maybe even .LOCK +^SC(TMGIEN):0
>>
>> In fact, without the timeout, if "someone" else has already locked
>> the
>> node, wouldn't this code just sit there until the node is unlocked?
>>
>> On Jan 6, 2009, at 6:26 PM, kdt...@gmail.com wrote:
>>
>

Using a timeout is required by the SAC, too. I should have mentioned
that.

[Gregory Woodhouse]

On Jan 7, 2009, at 5:13 AM, kdt...@gmail.com wrote:

> So are you saying that even if another process locks a node, then I
> can still write to that node? So locking has no "teeth" so to speak?
>
> So then have a working lock system depends on each process respecting
> the lock system, i.e. checking with a lock command before writing?
>
> Interesting...
>
> Kevin

Yes.

[Steven McPhelan]

From this original code snippet it is impoosible to say that "someone has the SC record locked".  Your ELSE command is dependent upon the $TEST value.  There is no code above indicating how $TEST was set.  Apparently when this code was run $TEST=0 and thus the ELSE command is valid.  The LOCK immediately above the ELSE had absolutely zero bearing upon the value of $TEST until you introduced the timed LOCK command.

[skip ormsby]

And speaking of timed Lock and time outs in general, I would highly recommend to *never* use the value of zero.  Zero can produce a non-sense value, just as 89/0 or 0/0.  All computer instructions take some bit of time, even if it is a fraction of a second.  The time out is just the maximum amount of time to wait and not a minimum amount of time to wait.  So for example if you: L +^ABC(123,IEN,0):1 and it takes 0.00001 second to get the lock, the waiting period will be satisfied in less than 1 second.
If you use zero it could work quite will on your test system, but fail in a clustered environment.  Reference: patch DI*22*147