ILE RPG has two modes of operating in a multithreaded environment: concurrent and serialized. Each mode has advantages and disadvantages. You can choose which mode of operation fits each module in your application.
| Issue | THREAD(*CONCURRENT) | THREAD(*SERIALIZE) |
|---|---|---|
| Is source-modification required to achieve thread-safety (other than coding the THREAD keyword)? | No, although some source-code modification may be necessary to reduce the amount of static storage used by the module, if the number of concurrent threads might be very large. | No |
| Is there a deadlock risk due to the handling of static storage within the module? | Yes, if SERIALIZE is coded on a Procedure specification. | Yes, the risk is high. Deadlock is possible at a module level. If THREAD_A is in module MOD_1 and THREAD_B is in module MOD_2, and each thread is trying to call a procedure in the other module. |
| Does the module get the benefits of running multithreaded? | Yes | No |
| Is there a risk of bottlenecks? | Yes, if the SERIALIZE keyword is coded on a procedure specification. | Yes, the risk is high. The serialization of access to the module can cause the module to act as a bottleneck within the application. If one thread is active in the module, other threads must wait until the first thread is no longer running in the module, in any procedure. |
| Is thread-local storage supported? | Yes, it is the default type of static storage. | No |
| Is all-thread static storage supported? | Yes | Yes, it is the only supported type of static storage. |
| Can the RPG programmer choose whether a static variable is thread-local or shared by all threads? | Yes | No, only all-thread static storage is supported. |
| Is there a concern about the amount of memory required at runtime? | Possibly. The amount of static storage needed for the module is multiplied by the number of threads using the module. | No, all threads use the same static storage. |
| Who is the intended user? | An RPG programmer who wants the performance benefits of running in multiple threads, who is either willing to accept the amount of thread-local static storage used by each thread, and/or willing to rewrite the RPG module to use the least amount of static storage possible. | An RPG programmer who does not wish to rewrite the module to reduce the amount of static storage, or who is concerned about the additional storage per thread required by THREAD(*CONCURRENT). The RPG programmer is willing to accept the fact that the module can act as a bottleneck if more than one thread wants to run a procedure in the module at the same time. |
For more information, see Multithreading Considerations.