Re: Impact of control option thread(*concurrent)

Thank you Barbara for the clarification ... and in this particular example
you are pointing out here I prefer to use the locksl/unlocksl MI on a i.e.
userspace data or other share memory or a semaphore to avoid to confuse my
self. It work much like the EnterCriticalSection() you can find in other
operation systems. Maybe EnterCriticalSection() would be a good candidate
for a RFE.


On Fri, Mar 15, 2019 at 11:59 AM Barbara Morris <bmorris@xxxxxxxxxx> wrote:

On 2019-03-15 4:10 AM, Niels Liisberg wrote:

Also notice how you use it: If you call "not treadsafe" stuff like old

RPG

programs, some CL commands, where you create temporary stuff in QTEMP

etc.

- The you HAVE TO use *SERIALIZED. What it does is simply making a lock
that will remain locked until the procedure terminates - allowing you to
make all the non-thread safe stuff.

You could also have a procedure with the SERIALIZE keyword in a
THREAD(*CONCURRENT) module.

But either way, you'd have to ensure that using that THREAD(*SERIALIZE)
module or that procedure with the SERIALIZE keyword is the _only_ way to
do the non-thread-safe stuff.

For example, if there's a possibility of two different
THREAD(*SERIALIZE) modules calling an old RPG program, then those calls
would not be thread-safe.

--
Barbara

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com