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/ |