TechTip: Running RPG Programs in Multi-Threaded Jobs

[Guest.Visitor]

TechTip: Running RPG Programs in Multi-Threaded Jobs

** This thread discusses the article: TechTip: Running RPG Programs in Multi-Threaded Jobs **
It seems to me that people here are choosing performance over data integrity. Which option do you think the CEO, CIO, CFO, stock holders, BOD, etc would prefer? I ran some tests. I encourge others to do the same. I ran several tests over a program with and without Thread(*Serialize), 5,000,000 iterations over several tests. The performance is nearly the same, sometimes the Thread(*Serialize) actually wins. I imagine that database I/O will the bottleneck in most RPG modules, not Thread(*Serialize). Sure wish Barbara would add some input... Chris

[B.Morris]

TechTip: Running RPG Programs in Multi-Threaded Jobs

** This thread discusses the article: TechTip: Running RPG Programs in Multi-Threaded Jobs **
Sorry, I didn't realize this discussion was going on. As Chris found in his tests, there is very little overhead from coding THREAD(*SERIALIZE). One problem I see with coding THREAD(*SERIALIZE) everywhere is that it might give the illusion that all the RPG code was now thread-safe. But it's not necessarily safe; coding *serialize just brings an RPG module to the same point as a module written in say a C module with no static storage. Ensuring thread-safety involves much more than just protecting the access to the static storage.

[B.Morris]

TechTip: Running RPG Programs in Multi-Threaded Jobs

** This thread discusses the article: TechTip: Running RPG Programs in Multi-Threaded Jobs **
Chris said: "4. Does coding Thread(*Serialize) still create just object? I swear I read a while back that this creates 2 objects, 1 hidden. " Then Tom said: "4. I remember hearing or reading the same thing. the second object somehow enforces the serialization. " What do you mean by "object"? Coding THREAD(*SERIALIZE) just causes the compiler to generate code to synchronize access to the module. At runtime, a mutex is created for each synchronized module. If the module runs in different activation groups, each AG would get its own mutex (since the static storage for each activation group is separate, the synchronization is also separate). The mutex isn't hidden though; you can see it in DSPJOB or WRKJOB, option 19.

[R.Daugherty]

TechTip: Running RPG Programs in Multi-Threaded Jobs

** This thread discusses the article: TechTip: Running RPG Programs in Multi-Threaded Jobs **
Well, I did get it, but I chose to say that synchronizing at the module level and letting calls complete like reading a dataq is a good thing. The RPG to RPG on downstream in the thread I missed though, thanks for pointing that out. I also saw Barbara's explanation of the mutex mechanism. The automatic synching in hindsight is false protection, as only stateless subprocedures could be called from multiple threads, or web pages in the case of the jobs site server I wrote, without overwriting data from the other thread that was counted on being there next time it called. So *Serialization would the the easiest part of making sure a module was ready to participate in multiple threads. rd