Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

TechTip: Running RPG Programs in Multi-Threaded Jobs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • TechTip: Running RPG Programs in Multi-Threaded Jobs

    Would it be possible to add a new function/opcode in future RPG to synchronize the update of global/static variables like synchronize; eval global_ctr += 1; end-synchronize; so that it would only block the statement that updates the global/static variable and not the whole module?

  • #2
    TechTip: Running RPG Programs in Multi-Threaded Jobs

    The reason RPG needs the module-wide synchronization is because of the hidden static storage that the RPG compiler uses to make the RPG module work correctly. If the only static storage in the module was the static variables you declared yourself (including any global variables), then it would indeed be possible to have statement-level synchronization like you suggest.

    Comment


    • #3
      TechTip: Running RPG Programs in Multi-Threaded Jobs

      Barbara, Thanks for all the feedback. In the book "Java at Work", on page 333, author Jim Barnes writes: Next I have coded a compiler directive at Label G that will enable me to use the same source code to generate both a threadsafe version of the service program and a single-threaded version for pure native applications. This is done to enable Java threads of execution to be serialized for each all instance of your native methods. Yet you will want to avoid serialization when other RPG programs call your service program. Maybe I read too much into this statement. Thoughts? Chris

      Comment


      • #4
        TechTip: Running RPG Programs in Multi-Threaded Jobs

        Thanks to everyone who participated... Shane, Hans, David, Ralph, Chris, Gio, and Barbara for the article and her participation (hope I didn't leave anyone out). I now understand multithreading and serialization, and, may even be able to talk intelligently about them. Tom.

        Comment


        • #5
          TechTip: Running RPG Programs in Multi-Threaded Jobs

          Chris, that author was advocating explicitly building two versions of the service program, by coding something like the first example in the raw code below, and then compiling once without DEFINE(MULTI_THREAD) and once with it. I haven't seen that book, but if he was using the same source code for Java native methods and ordinary procedures, he probably also had something like the second example in the raw code for the prototypes for the native methods. If your procedure is a native method, you can't call it without Java being involved. A native method gets called through Java, like any other Java method, even if it's in the same module as the caller. If you were going to that trouble (and it seems like a good idea if you want to call your procedures either from Java or from RPG but not mixing the two), then it makes sense to condition THREAD(*SERIALIZE) with the same DEFINE.
          Code

          Comment


          • #6
            TechTip: Running RPG Programs in Multi-Threaded Jobs

            Barbara, I think you figured it out. He was using JNI. So the solution is apparently to specify different object names on the compile. Do you happen to know if CLLE is threadsafe if called from Java? I'm wondering if Java should ever call a CLLE program. I think the odds of having a problem are small. One JVM would have to have multiple threads using the *same* iSeries connection job (right?). Chris

            Comment


            • #7
              TechTip: Running RPG Programs in Multi-Threaded Jobs

              And that (multiple threads on one connection) doesn't work very well. The second will block on the first until its call completes. That's why I like to assign one connection job per HTTP session. Joe

              Comment


              • #8
                TechTip: Running RPG Programs in Multi-Threaded Jobs

                Ha. Good to know Joe. Now we've come full circle. This tells me that OPM CL programs are threadsafe, because of the blocking. And why would I need to add Thread(*Serialize) then? Maybe all this is needed *outside* the context of an HTTP server (servlet engine). Chrhis

                Comment


                • #9
                  TechTip: Running RPG Programs in Multi-Threaded Jobs

                  I am thinking this problem would have cropped up quickly for a shop that was calling RPG utility routines in a service program from multiple threads in a Java program, probably same kind of work for each thread but they were launching a thread for each "job", if you will, versus let's say just a main line thread and a sockets communications thread. I take it from this discussion that one instance of the service program would be called into the job space of the Java program and multiple threads could be calling subprocedures in it at the same time at some point. It's probably pretty knarly because of timing of conflict and I gather doesn't cause a crash, but rather generates "unpredictable" results when there is a conflict, those results only seen as side effects at some point in output. Java people would launch an instance of their equivalent object for each thread, thus no conflict. We, having job oriented architecture where people parse work out to jobs, not threads, have a job ready program sucked into an architecture that wouldn't have any qualms generating as many instances of objects as they have threads. If there isn't, there needs to be an object wrapper interface to do the same thing with RPG programs. If it's good enough for Java, I don't see why we should be efficient and take the blame. rd

                  Comment


                  • #10
                    TechTip: Running RPG Programs in Multi-Threaded Jobs

                    ** This thread discusses the article: TechTip: Running RPG Programs in Multi-Threaded Jobs **
                    ** This thread discusses the Content article: TechTip: Running RPG Programs in Multi-Threaded Jobs **
                    0

                    Comment


                    • #11
                      TechTip: Running RPG Programs in Multi-Threaded Jobs

                      ** This thread discusses the article: TechTip: Running RPG Programs in Multi-Threaded Jobs **
                      Thread stupid here asking a question. I currently submit separate jobs for my multi-user communications work and have wondered if threads could hide some of the ugliness of such a technique. I have simply assumed that the lack of threading discussions involving RPG meant threading had requirements better suited to C. If I write a threaded app, it would need a main and set of procedures to carry out the needed tasks. Are you saying the threads can't be running any of these procedures concurrently only serially. If I understand this, why bother creating threads if you can't actually de-serialize the work load? And then why doesn't the main have the same problems?

                      Comment


                      • #12
                        TechTip: Running RPG Programs in Multi-Threaded Jobs

                        ** This thread discusses the article: TechTip: Running RPG Programs in Multi-Threaded Jobs **
                        ShanePoad asked: why bother creating threads if you can't actually de-serialize the work load? Good question. Let's back up for a moment. Threads are typically used when handling requests in a TCP/IP server application. If a request can be handled quickly, then an answer can be returned immediately. But if there might be some latency involved in putting together an answer (such as accessing disk storage), the preferred approach is to spawn off a thread. (You could start a new process too, but that has additional overhead that's often not necessary. Basically, you don't want to introduce any unnecessary delay in processing the request.) In the past, it was usually only the systems programmer who needed to worry about this. However, these days you have HTTP servers, which may well call out to application code. Now back to your question, which I'll rephrase slightly: Why use RPG code in a multi-threaded environment if it's going to block requests at the RPG procedure level? That is, allow only one invocation of any procedure to be active at one time, thus totally eliminating any advantage that multi-threading might give you? Hmmm... Hmmm... Hmmm... Here are two possible answers: 1) You don't want all your nice existing RPG code to go to waste. 2) You don't want to learn Java or C. (Or any of dozens of other languages that handle threading better.) Sorry, I can't think of any other reasons why you would use RPG in a threaded environment. But I'm sure others with a better knowledge of the language can help. Cheers! Hans

                        Comment


                        • #13
                          TechTip: Running RPG Programs in Multi-Threaded Jobs

                          ** This thread discusses the article: TechTip: Running RPG Programs in Multi-Threaded Jobs **
                          Barbara Morris wrote: This causes the RPG compiler to generate code to ensure that only one thread can be running in any procedure in the module at any one time. I am by no means knowledgable in the area of threads but what I seem to know makes me believe that the aforesaid sentence appears to take away any reason for using threads at all. I'm afraid I need a bit of elaboration on this subject. Dave

                          Comment


                          • #14
                            TechTip: Running RPG Programs in Multi-Threaded Jobs

                            ** This thread discusses the article: TechTip: Running RPG Programs in Multi-Threaded Jobs **
                            I have a few thoughts / questions... 1. I think one of the points (#1) should be made clearer: Code Thread(*Serialize) in every module that could be in the call stack in a multi-threaded job. IE: If the call stack is 10 deep, all 10 need this H-spec. 2. Why wouldn't you just code Thread(*Serialize) in every single module then? 3. Are OPM CL programs already thread safe? CLLE programs? 4. Does coding Thread(*Serialize) still create just object? I swear I read a while back that this creates 2 objects, 1 hidden. Chris

                            Comment


                            • #15
                              TechTip: Running RPG Programs in Multi-Threaded Jobs

                              ** This thread discusses the article: TechTip: Running RPG Programs in Multi-Threaded Jobs **
                              Chris, I learned about this a few years back so my memory may be spotty. A company I was working at had me write some procedures that were going to be called by web applications. I think the web apps were written in Java but I'm not so sure. I haven't worked with threads since. My understanding is that: 1. If you know the modules will run in multithreaded jobs, all modules called in the job must use Thread(*Serialize). 2. Yes. Code all modules that will run in multithreaded jobs that way. 3. No OPM program is threadsafe. I don't know about CLLE. 4. I remember hearing or reading the same thing. the second object somehow enforces the serialization. I also understand that RPG programs, both OPM and ILE do not spawn multithreaded jobs. As a general rule, I'd stay away from running any RPG procedure in multithreaded jobs. This is a quote from the ILE RPG manual, Ch 13: Control Specifcations: "Normally, running an application in multiple threads can improve the performance of the application. In the case of ILE RPG, this is not true in general. In fact, the performance of a multithreaded application could be worse than that of a single-thread version when the thread-safety is achieved by serialization of the procedures at the module level. Running ILE RPG procedures in a multithreaded environment is only recommended when required by other aspects of the application (for example, when writing a Domino exit program or when calling a short-running RPG procedure from Java). For long-running RPG programs called from Java, we recommend using a separate process for the RPG program." Tom.

                              Comment

                              Working...
                              X