Re: Multithreaded Programming

[bmorris@xxxxxxxxxx]

Date: Wed, 28 Feb 2001 15:26:52 -0800
From: Jim Langston <jimlangston@conexfreight.com>
> ...
>If this is not the case, and if each can actually see the static
variables...
>
>D Locked        S       Like(*IN01) Static INZ(*Off)
>
> *** Probably need to do something to waste time in this tight loop ***
>C             DoW        Locked
>C             EndDo
>C             Eval       Locked = *On
>   Do Stuff
>C             Eval       Locked = *Off
>
>The whole theory behind this, however, is that these subroutines just
>process the calls for the shared (static) memory somehow.  Maybe somethign
>like...

Jim, that won't work.  What if two threads both find Locked='0' and both
set Locked='1' at exactly the same time?  With threads, you need to have
something that _always_ works, theoretically as well as actually.

There are mechanisms for protecting access to shared memory such as mutexes
and semaphores.  I would want to have a really good reason to try to share
static storage or user-space storage across threads or processes rather
than
use files and data areas since (as Rich already said) they already have
protection against two updates at the same time.

For sure with RPG, you have to code THREAD(*SERIALIZE) even if you're only
using automatic storage in your routines.  You only see half the picture,
looking at your own variables; the other half is RPG's control of things
like
the PSDS and other control structures (all module-wide, therefore static).

Multi-thread programming is very difficult, and should not be undertaken
without a thorough knowledge of all the issues involved.  Always assume
that
2 threads _will_ look at a variable at exactly the same time.

It's not only difficult to design and code for multiple threads, it's
very difficult to test.  If you have logic errors, you might not find out
about them until long after your code has gone into production.

Barbara


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---