Mumpster
http://mumpster.org/

Hierarchical LOCK and multi-processing, and $INCREMENT
http://mumpster.org/viewtopic.php?f=14&t=1770
Page 1 of 1

Author:  whitten [ Thu Feb 06, 2014 3:56 pm ]
Post subject:  Hierarchical LOCK and multi-processing, and $INCREMENT

One of the features long a part of MUMPS is the ability to lock a name "high" in the locknamespace
and get a lock on all the "lower" ones.

This means you don't have to be able to signal to other jobs that they should start processing, because the parent job may LOCK +^FLAG("Common name") and any participating job will LOCK +^FLAG("Common name",$JOB) and thus be in a wait state until the parent job unlocks using a command like LOCK -^FLAG("Common name") allowing all the sub-jobs to begin processing.
This will effectively work as a gun shot in the beginning of a horse race.

If the parent job then uses a LOCK +^FLAG("Common name") it will not be able to get the lock until all the sub-jobs are finished.

One thing about this method of communication is that it works regardless of how many sub-jobs there may be. Unfortunately, there is no way using solely the LOCK command to know how many there are. The $INCREMENT function allows this to happen, as it guarantees that only one job increments a global variable at a time. So each of the subjobs can use code like SET MYINDEX=$INCREMENT(^FLAG("Common name","Count") and thus have an independent workspace in the global variable ^FLAG("Common name",MYINDEX) and its subtrees.

The addition of $INCREMENT to the MUMPS Standard will allow for easier multi-programming, similar to other languages, It will also allow for coding using techniques that other programming languages use, and allow a transliteration style of porting code into MUMPS which was originally written in another language.

Author:  raynewman [ Thu Feb 06, 2014 4:56 pm ]
Post subject:  Re: Hierarchical LOCK and multi-processing, and $INCREMENT

I've never used $INCREMENT but it sounds like a reasonable idea.

To determine the number of locks held in a particular area, a $ORDER() on ^$LOCK() would work but is a little more long winded.

Ray

Author:  gwoodhouse [ Tue Mar 04, 2014 12:13 pm ]
Post subject:  Re: Hierarchical LOCK and multi-processing, and $INCREMENT

I think there are a lot of reasons for including $INCREMENT in the standard, and I believe it is supported by both GT.M and Caché. It's a little unclear to me what your example has to do with lock semantics (which are decidedly different in MUMPS and most other languages), but I agree that this provides a convenient way to manage private spaces within a global at a finer degree of granularity than $JOB.

Perhaps this is unrelated to what you had in mind here, but a feature of Caché I quite like is process private globals. The syntax is ^||Name where the process private global Name goes away when the process terminates. Using indices like $J or indices allocated with $INC has the (potential) disadvantage that the global nodes remain, even after they are no longer needed. It's not a big deal if temporary globals are not journaled, but it does mean programmers need to explicitly KILL ^TMP($J) - assuming ^TMP is the global you use for storage that should be private to a single process. Process private globals eliminate this problem. On the other hand, if you want storage be shared among processes, or persist beyond the life of a single process (this is what ^XTMP in the VistA environment is used for), $INC provide a great way to eliminate name collisions, or unnecessary contention, where a single node must be successfully locked in order to obtain a new subscript value.

Page 1 of 1 All times are UTC - 8 hours [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/