Serialization: Mutexes vs. Semaphores

IBM iSeries
I am looking for a way to serialize access to a RPG program across multiple jobs. I have been doing some research on mutexes and semaphores and I am wondering what the advantages/disadvantages of each are. Also if there are any other ways to accomplish this. Thanks in advance for your reply

Answer Wiki

Thanks. We'll let you know when a new response is added.


You can take a look to this link.

The title is “Synchronization techniques among threads”


Discuss This Question: 5  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Yorkshireman
    could you amplify 'serialise access across jobs' - you intend several jobs to use a single program? - you need several jobs to share something concurrently?
    6,085 pointsBadges:
  • Joy Stalnecker
    I have several different job flows that call the same program. I want to limit access to this program to one job at a time. So only one job will ever be running this program at any given time.
    170 pointsBadges:
  • Sloopy
    There is an old-fashioned method for restricting a program to a single caller at a time, which I am giving you here because it's quick to implement and needs no expertise beyond 'normal' programming knowledge - I hope that someone else can come up with the mutex and semaphore methods. I would love to try them! In the *INZSR of the RPG program, write a loop to lock a data area: C DoU not *In91 C *Lock In PGNAME 91 C EndDo At the end of the program (when *INLR is set on before returning to the caller), unlock the data area: C Out PGNAME (In this example, the data area is assumed to have the same name as the program, which is reasonable.) The first job to call the program will get the lock. Subsequent callers will stick in the loop, waiting for the time determined by the class of the object (I think it's 60 seconds for a data area) in each run through the loop. When the first job leaves the program it unlocks the data area and the next job to start a *LOCK IN operation on the data area will get it. There is no 'proper' serialisation here, in that you can't guarantee that the second caller will get the next call, the third the call after that and so on. It's first lock, first served. Regards, Sloopy
    2,195 pointsBadges:
  • WilsonAlano
    Hi, Scott Klement wrote a good article about semaphore uses here: Regards, Wilson
    2,710 pointsBadges:
  • TomLiotta
    In general, if you want only one job at a time to run a program, just have the program place an exclusive lock on itself when it starts and release the lock when it finishes. For ILE RPG, the *PSDS contains the object name of the program and the library it's running out of.
    ALCOBJ     OBJ(( mylib/thispgm *PGM *EXCL)) WAIT(60) program logic here...
    DLCOBJ     OBJ(( mylib/thispgm *PGM *EXCL))
    But usually it's not the program that should be "serialized"; rather, resources used by the program need to be protected. Place locks on the appropriate resources and it doesn't matter how many jobs are running the program. Further, without placing locks on the resources, a second program can do the same processing as the program being "serialized". That totally defeats the intention making it pointless. Tom
    125,585 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: