Comments on: Serialization: Mutexes vs. Semaphores

By: tomliotta

tomliotta — Mon, 12 Oct 2009 04:49:37 +0000

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)

…do 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

By: wilsonalano

wilsonalano — Mon, 24 Aug 2009 17:48:57 +0000

Hi,

Scott Klement wrote a good article about semaphore uses here:

http://systeminetwork.com/article/get-synch-semaphore-sets

Regards,
Wilson

By: sloopy

sloopy — Mon, 24 Aug 2009 15:39:41 +0000

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

By: joy stalnecker

joy stalnecker — Mon, 24 Aug 2009 11:53:35 +0000

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.

By: yorkshireman

yorkshireman — Mon, 24 Aug 2009 08:07:37 +0000

could you amplify

‘serialise access across jobs’

- you intend several jobs to use a single program?
- you need several jobs to share something concurrently?