Highlighted
Absent Member.
Absent Member.
2393 views

[archive] Threading

[Migrated content. Thread originally posted on 04 December 2002]

We are using threading with Acucobol 5.2.x and we have a particular problem. If you call in a thread program X which then calls another program (program Y)(not in a thread) and then from the main thread you call in a thread program X again which then calls another program (program Z)(not in a thread). When you exit either program Y or program Z, program X either terminates completely or terminates the entire application. Even though there are two threads running (not including the main thread)

eg. program A
----program X (thread)
--------program Y
----program X (thread)
--------program Z

we have used thread locking and many other combinations without success.

Any help on this would be great.
0 Likes
5 Replies
Highlighted
Absent Member.
Absent Member.

RE: [archive] Threading

The only reason I can think of that will cause this problem, is that you have a "STOP RUN" statement in program Y or Z.

Solution: put an "EXIT PROGRAM" statement before the "STOP RUN" statement or use the "GOBACK" statement instead.

I have tested with four little programs and start them the way you explained and it works fine.

Andr
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Threading

Thanks, but yes we have 'EXIT PROGRAM' in all of the programs.

The situation only occurs when you exit from either program Z or Y
Program X terminates in both threads leaving program Z or Y hanging out there and when it terminates it terminates the whole system.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Threading

I was afraid my solution was too simple 🙂

Some time ago I had problems with unexpected termination of the whole runtime system when I exit a called program (not in a thread), but I cannot reproduce it anymore.

Maybe you should report this to Acucorp technical support.

Andr
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Threading

Is program X threadsafe? All writes to shared data in program X should be protected via lock thread, especially looping variables and stuff like that. Two threads that call the same program share the same memory.

Another 'gotcha', probably unrelated to your problem, is that non cobol calls will lock ALL the threads, for example w$getkey. Don't try and mix non cobol code in threading situations except for the most trivial cases.

Remember, in threading having more than one thread manipulate the GUI (character or otherwise) is a recipe for disaster. (please forgive me if I underestimate your programming skill). In cobol, its not so easy to have each thread own its own copy of data, so you have to be very careful. Threading in a non oo environment is a complex programming challenge.

Consider writing worker thread code into copybooks somehow. This will give you better data isolation and then you can use perform in thread instead of call in thread. If that's not possible, wrap every data write with a lock thread and log the value to a file to ensure you don't have a data conflict. Also, try making two complete copies of your wsf section in program X and hack a switch to have two threads write to either copy.

The worst case scenario is you have a stack problem introduced by the threading which is causing the runtime to terminate. This of course would not be your fault but would have to be worked around, say by the copybook approach.

Merlin
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Threading

Is program X threadsafe? All writes to shared data in program X should be protected via lock thread, especially looping variables and stuff like that. Two threads that call the same program share the same memory.

Another 'gotcha', probably unrelated to your problem, is that non cobol calls will lock ALL the threads, for example w$getkey. Don't try and mix non cobol code in threading situations except for the most trivial cases.

Remember, in threading having more than one thread manipulate the GUI (character or otherwise) is a recipe for disaster. (please forgive me if I underestimate your programming skill). In cobol, its not so easy to have each thread own its own copy of data, so you have to be very careful. Threading in a non oo environment is a complex programming challenge.

Consider writing worker thread code into copybooks somehow. This will give you better data isolation and then you can use perform in thread instead of call in thread. If that's not possible, wrap every data write with a lock thread and log the value to a file to ensure you don't have a data conflict. Also, try making two complete copies of your wsf section in program X and hack a switch to have two threads write to either copy.

The worst case scenario is you have a stack problem introduced by the threading which is causing the runtime to terminate. This of course would not be your fault but would have to be worked around, say by the copybook approach.

Merlin
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.