It is currently Mon Mar 18, 2024 11:13 pm


All times are UTC - 8 hours [ DST ]




Post new topic Reply to topic  [ 3 posts ] 
Author Message
 Post subject: Hierarchical LOCK and multi-processing, and $INCREMENT
PostPosted: Thu Feb 06, 2014 3:56 pm 
User avatar

Joined: Wed Nov 17, 2010 4:02 pm
Posts: 71
Location: Houston TX
Real Name: David Whitten
Began Programming in MUMPS: 06 Jan 1982
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.


Top
Offline Profile  
 
 Post subject: Re: Hierarchical LOCK and multi-processing, and $INCREMENT
PostPosted: Thu Feb 06, 2014 4:56 pm 
User avatar

Joined: Mon Nov 01, 2010 3:33 pm
Posts: 104
Location: Australia
Real Name: Ray Newman
Began Programming in MUMPS: 01 Jul 1976
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


Top
Offline Profile  
 
 Post subject: Re: Hierarchical LOCK and multi-processing, and $INCREMENT
PostPosted: Tue Mar 04, 2014 12:13 pm 
User avatar

Joined: Mon Jan 31, 2011 12:03 pm
Posts: 27
Location: Watsonville, CA (USA)
Real Name: Greg Woodhouse
Began Programming in MUMPS: 01 Oct 1992
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.


Top
Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC - 8 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Theme created StylerBB.net