× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Jon Paris wrote:

I wouldn't try it until V6R1 is available Larry. I'll leave it to Barbara to provide a definitive answer - but I believe that the problem is that you _can't_ "protect critical code" - because some of the most critical pieces are in the RPG runtime which is not thread safe until V6R1. Therefore without an intimate understanding of which bits of run-time are used when, you have no way of protecting it.


Jon, the ILE RPG runtime has been thread-safe since V4R4 when we added THREAD(*SERIALIZE). With *SERIALIZE, the serialization only applies to individual RPG modules; the runtime itself can be run simulaneously from multiple threads even in V4R4.

But what you say is true in spirit. Prior to V6R1, you can't rely on mutexes to protect the static storage within your RPG module, because you would need an intimate understanding of the code generated for your RPG module to know what bits rely on static storage. (Well actually, you don't need much intimate understanding - _every_ procedure relies on some static storage, so it's impossible to make an RPG module thread-safe without the THREAD keyword.)

So, while it's possible to create threads in RPG prior to V6R1, you have to work within RPG's module-serialization to be thread-safe. The only reason to use mutexes prior to V6R1 is when some resource is shared across RPG modules.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.