Filter
Top Products
Multithreading Considerations
| complete their calls, since each module will be locked by the thread in the other
| module. This type of problem can occur even with serialization of calls to a module
| and is referred to as deadlock.
|
Figure 74. Deadlock Example
| This example shows that you cannot access more than one procedure in the same
| module at the same time using ILE RPG synchronization techniques.
| To avoid the problem in the above example and ensure thread safe applications,
| you can control the synchronization of modules using techniques provided by C or
| by platform functions. Any callers of PROC1 or PROC3 for each thread should do
| the following:
| 1. Restrict access to the modules for all threads except the current thread, always
| in the same order (MOD1 then MOD2)
| 2. In the current thread, call the procedures in the modules (PROC1 and PROC3)
| 3. Relinquish access to the modules for all threads in the reverse order of step 1
| (MOD2 then MOD1).
| One thread would be successful in restricting access to MOD1. Since all users of
| MOD1 and MOD2 use the protocol of restricting access to MOD1 and MOD2 in that
| order, no other thread can call procedures in MOD1 or MOD2 while the first thread
| has restricted access to the modules. In this situation you have access to more
| than one procedure in the same module at the same time, but since it is only avail-
| able to the current thread, it is thread safe.
| This method should also be used to synchronize access to shared storage.
160 ILE RPG for AS/400 Programmer's Guide