Re: Multithreaded Programming

Barbara,

This type of locking has been used for a number of years for file
and record locking in a number of applications without any problems,
admittedly on PCs though.

Admittedly, this type of locking is normally used as a preface to calling
a file lock on a file before proceeding.

There are other schemes I have tried through the years to prevent deadlocks,
one being for the program I was locking to set the locking variable to a
unique value, then check to make sure that that value was the same.

D Locked      S    10A INZ(*Blanks)

C             DoW      Locked <> '1A345'
C             DoW      Locked <> *Blanks
C             EndDo
C             Eval     Locked = '1A345'
C             EndDo

First, the '1A345' would have to be a unique value for this thread.

Thread A sees Locked is empty
Thread B Sees Locked is Empty
Thread A sets locked to '1A345'
Thread B sets locked to '678AB'
Thread A sees Locked is not '1A345' and goes back into loop
Thread B sees locked is '678AB' and continues

In this scenario this would not work...
Thread A sees Locked is empty
Thread B sees Locked is Empty
Thread A sets locked to '1A345'
Thread B pauses
Thread A sees locked is '12345' and continues.
Thread B sets locked to '678AB'
Thread B sees locked is '678AB' and continues.

Then again, OS/400 has the system arbitrator just to handle this kind
of stuff.  Are there any system APIs we can make to the Arbitrator to
set our own logical locks?

Regards,

Jim Langston

bmorris@ca.ibm.com wrote:
> 
> 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
+---