This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: Maureen Ballard <address@hidden> >Organization: UK Ag Weather Center >Keywords: 199902231422.HAA28442 >Steve, > >Do you have any references you could point me to concerning semaphore >setup? The little I have been able to read about this makes me believe >that this is the answer to our problems. Unfortunately, our programmer >is new to unix and doesn't know much about it and I can't seem to find >anything on the web. If you could point in a direction I'd really >appreciate it. > >Thanks!!! > >Maureen > >-- >======================================================================== > >Maureen Moore Ballard address@hidden >Staff Meteorologist ph: 606-257-3000ext244 >Ag. Weather Center fax: 606-257-5671 >243 Ag. Engineering Bldg >Dept. of Biosystems and Ag. Engr. >University of Kentucky >Lexington, KY 40546-0276 >HOMEPAGE http://wwwagwx.ca.uky.edu > >You don't stop laughing because you grow old; >you grow old because you stop laughing. >========================================================================= > > > Maureen, Semaphores, and/or mutual exclusion is a basic computer science operating systems topic- that would be the most likely reference. Sometimes books teach the concept with 2 ships passing in a chanel. To implement semaphores in scripts, you want to employ a lock-out system where only one script is allowed to run at a time. A key is used, so that only one script at a time can have access. When that script is finished, it removes the lock and the next script to get the key runs. The main thing to remember is: if your script dies, then the old lock won't be removed- generally I have a stuck script email me if its waiting to long. Here is a basic lock-out routine for a csh. If all your scripts operate in a single directory and have this preample, you can keep execution to 1 at a time. #!/bin/csh -f # use process ID to get a unique lock name, touch creates the lock file # in the directory. set MYLOCK=".lock.$$" touch $MYLOCK # wait until it is my turn, be sure to sleep before each test @ COUNT = 0 set TURN=0 while ($TURN == 0) sleep 5 # find the first lock set LOCK=`ls -rt .lock.* | head -1` if($LOCK == $MYLOCK) set TURN=1 @ COUNT = $COUNT + 1 # usually employ some way to notify the user if a job is waiting # too long. Exiting prevents too many jobs from backing up. if($COUNT > 120) then echo "Check on semaphores" | mailx -s "semaphore" address@hidden remove $MYLOCK exit endif end # if reached here, its our turn. Remember to remove lock at end # do some processing here # simulate some process running echo job $$ is running sleep 10 # last thing to do is remove our lock rm -f $MYLOCK exit You can test the above script (eg test.csh) with something like: at the csh prompt: % @ COUNT = 1 % while ($COUNT < 11) ? test.csh & ? @ COUNT = $COUNT + 1 ? sleep 1 end The above test will start up and background 10 instances of the test.csh script. As each one gets its turn, it will echo a like similar to "job 1004064 is running". Steve Chiswell