Multithreaded Applications

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.

The RPG support for threads ensures that your static storage is handled in a threadsafe way. However, you are responsible for other aspects of thread-safety for your application. You must ensure that all the programs that your application uses are threadsafe, that you manage any shared storage in a threadsafe way, and that you only use those aspects of the system that are threadsafe.

Table 27. Comparison of thread-safety modes in RPG
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.



[ Top of Page | Previous Page | Next Page | Contents | Index ]