Re: Java->RPG, *SERIALIZE required?

Justin,


It kind of depends on what the RPG code is doing ...?

If it is a fairly short-running function that returns a value, you likely would never notice that THREAD(*SERIALIZE) is doing anything.  It creates a MUTEX lock to ensure that two threads do not enter the same procedure at the same time.  On return from that procedure, the MUTEX lock is released, allowing the next caller who may be waiting on that MUTEX to have access. (Threads will queue up automatically, FIFO, waiting on the MUTEX lock.)


You can also try THREAD(*CONCURRENT) but you need to read the manuals and understand the nuances of what that really does.  You cannot just stick "H THREAD(*CONCURRENT) on any old RPG code and expect that it will work correctly in a multi-threaded job.


Hope that helps,


Mark S. Waterbury


On Friday, March 6, 2020, 1:11:03 PM EST, Justin Taylor <justin@xxxxxxxxxxxxx> wrote:

" Now I'm curious why you believe that thread(*serialize) might be undesirable in your current project?"

Because it's multi-threaded, and a single-threaded bottleneck would be undesirable.

Thanks



-----Original Message-----
From: Nathan Andelin [mailto:nandelin@xxxxxxxxx]
Sent: Friday, March 06, 2020 11:46 AM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Java->RPG, *SERIALIZE required?

I might quibble with the assertion that you "must" thread(*serialize) in that a lot of Java processes are single threaded; No need to serialize in that case. Also it is conceivable that one could write RPG code that didn't require *serialized access. But on the whole, thread(*serialize) is good advice, in that it ensures safe access to the RPG code from multi-threaded callers.

Now I'm curious why you believe that thread(*serialize) might be undesirable in your current project?