×
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.
<Mihael>
I was wondering if there is any significant overhead by (or reason against)
compiling all RPG programs and service programs with THREAD(*CONCURRENT)?
Usually I only have the constellation that only one thread per job is
created. Though when using frameworks like ILEastic multiple threads per job
are used. Then every program/service program in the call chain should
support multithreading.
</Mihael>
Hi Mihael,
IMHO overhead wouldn't be a problem, it's overestimated in the RPG
community!
Stability would be the main problem to me. Only very few RPG programms are
compiled, specifying the THREAD keyword and there might be undetected bugs
in the RPG runtime, maybe even fixed bugs coming back with a new release.
The RPG reference is telling, that THREAD(*CONCURRENT) is making all static
storage threadlocal. This would work very diffrent from Java or other modern
languages: a thread, doing some work, changing the state of the process the
change would not be seen in other threads, this might produce very strange
effects and has to be circumvented in application design.
It seems to be possible to use static variables, declared with
static(*allthread) and protect it by using synchronized procedures (in
recent releases).
There are some hints in the RPG reference (explicit import/export <I don't
use anyway>, using pointers and procedure pointers <procptr I'm using in
every programm - CEE4RAGE>, *INxx should be no problem< a must not use
feature anyway>
Dieter
midrange.com
