Hello, I'm relatively new to the world of AcuCOBOL.

I'm working on multi-thread programs (on Windows machine) and I was not able to understand the resulting behavior. So I have a couple of questions.

Does the runtime really create different system-threads for every COBOL-threads calls ?

If I have a cpu-intensive thread, does the runtime give in any case some resources to the other threads or I need to slow-down the first one (i.e. adding explicit sleep instructions) ?



  • Consider the runtime is a single executable and that traditionally a COBOL program would do it's call sub-programs sequentially .. by using threads the COBOL program can call a sub-program and have that program run while the caller program is still running. The threading is done within the runtime, the runtime does not leverage any system routines (such as Hyper-V). The runtime does not monitor nor is it aware of what load your program or programs need, that is up to you to manage. With threads you can also use messages so you can make your sub-programs report what their status is (i.e.75% done).

  • Ok.

    If the runtime does not create system-thread I assume that my applications does not take advantage of using multi-core CPU. And I cannot use any Windows thread-scheduling knowledge.

    My actual problem is exactly related to the visualization of the percentage. The background worker thread consumes a lot of resources (CPU and I/O) and the graphical window remaining freezed (e.g. 10%) until the thread ends.

    Could  the variables IO_SWITCH_PERIOD and DISPLAY_SWITCH_PERIOD be useful ?

  • For the single execution of the rutime, yes it does not take advantage of using multi-core CPU. However, when you have mutiple runtimes executing, the O/S may take advantage of using multi-core CPU.

    It is possible that IO_SWITCH_PERIOD and DISPLAY_SWITCH_PERIOD may be useful, you'd have to experimant to see if they help you. If the load issue is based on calling a program that makes a report you might consider using AcuConnect Distributed processing (even though AcuConnect would be on the same server as the runtime) and C$ASYNCRUN - Call C$ASYNCRUN along with your remote applications to allow AcuConnect to run asynchronously... this would allow your report program to run effectively independent of the display program.

  • Hi shjerpe, i'm a Davide's colleague. Thank you for your replies, but what davide was trying to find out is why a cpu intensive thread frezees al others running threads. In particular we have a background worker thread that perform a huge amount of delete on three different files; when this thread starts (on pcs that are 2 or 3 years dated)  the GUI become totally unresponsive and by clicking on any button Windows says that the window is not responding. We already know that the background thread is still working but our costumer doesn't, so they directly kill the wrun32 process. Please don't answer to try out "mass update", "bulk addition" or so; we already tried and they just make the process even worse as they take such a CPU load on the server that even other terminals that try to connect have speed degradation.

    We are just trying to figure out how the multithreading works on Acu runtime, and if it is a real multithread (like you can achieve using any other language like C , C#, Java, Python and so on) or it is a proprietary implementation that tries to emulate it.

  • Verified Answer

    Threading has been available in Acu for sometime, it is a proprietary implementation. However, the runtime is not a thread-safe executable and this is one of the reasons that Acu hasn't been able to leverage O/S that do provide multi-threading like Hyper-V. If you can de-couple the programs that perform a huge amount of delete on three different files ... perhaps you can run them using C$SYSTEM or C$RUN or use AcuConnect Distributed processing to run these file intensive programs while the GUI program continues to run as well.

  • Ok we understood. But the goal in using multithreading is to perform multiple procedures with the perception of doing them concurrently; does it exist a way in acucobol to have a threaded procedure that executes many i/o without freezing the main thread on dated PCs? C$SYSTEM or C$RUN is not a suitable option.

  • Add this to your background process.

       accept is-there-a-key-pressed from input status.

    You won't actually do anything with the result from input status for your situation. The accept frominput status will return control to the windows os for a brief time.  Basically your program will be 'checking in' to say that it is still alive.

    Here is our solution in context...

    77  is-there-a-key-pressed      pic 9.

        88 there-is-a-key-pressed   value 1 when false 0.


    start x-file

          invalid set eof to true

    not invalid set eof to false


    perform until eof

      perform check-for-excape-key-press

      if i-want-to-quit

        set eof to true


        read x-file






       set i-want-to-quit to false





          IF YES-ENTERED

             set i-want-to-quit to true




       set there-is-a-key-pressed to false

       move spaces to key-being-pressed

       accept is-there-a-key-pressed from input status.

       if there-is-a-key-pressed

          accept key-being-pressed LINE 1 POS 1 OFF time 1 auto.

  • Threading certainly allows you to have multiple programs processing concurrently. Let's discuss your I/O .. where are the data files .. I'll take a guess that they are on a mapped drive (i.e. Z:) .. one of the underlying issues with using a mapped drive will be performance and potentially file corruption .. are your data files residing on a mapped drive? If so, have you tried using AcuServer? Many of our customers present a "progress bar" type of dialog when their application does something intensive. This would present a clue to the user to wait until the progress bar disappears and then their screen is ready for user input.

  • Data are on the same local drive of the wrun32 and we perform this process in thread just because we don't want our users to wait for procedure ending, otherwise we could have put this procedure in the main thread with a progress bar avoiding any kind of multithreading coplexity.

    However the workaround suggested by DMiller seems to work, the procedure in thread is a bit slowed down but at least it doesn't freeze anymore.

    Thank you for support.

  • I apologize for being late in responding.  Setting the Runtime configuration "FILE_IO_PEEKS_MESSAGES" to "ON" or "FILE_IO_PROCESSES_MESSAGES" to "ON" usually helps prevent locked up screens during heavy i-o.