I have some experience of multi thread programming on Unix and Windows (mostly C and Modula-2) and I have tons of experience of non-multithreaded RPG and C on the iSeries. I agree totally with what Bob is writing, multi-threading very soon get out of control if you don't design it absolutely right.
My experience from developing a middleware system on the S/38 and iSeries is that you come a very long way without threads. This system is dynamic multi-process (can be 100+ processes) and all process communication and synchronization is using data queues and the DB/2. You gain a lot if you can stick with multi-process, since you have OS inherited process isolation which guaranties that one process cannot, in any way, get things mixed up for another process. You need to invent some functions for spawning new processes and creating dynamic dataqueues, new jobqueues and so on but that's something you can build in a day or two without having to feel you're out at deep water.
From: c400-l-bounces+joakim.lindbom=capgemini.com@xxxxxxxxxxxx [mailto:c400-l-bounces+joakim.lindbom=capgemini.com@xxxxxxxxxxxx] On Behalf Of Bob Crothers
Sent: den 3 mars 2010 18:52
To: C programming iSeries / AS400
Subject: Re: [C400-L] Anybody know anything about threads and multi-thread jobs?
I've also had extensive experience with threads and multi-threading. Just not on the AS/400, but the concepts are all the same.
Some things to remember:
1) It makes debuging a lot harder!
2) Never allow 2 threads to modify the same chunk of data at the same time.
*ALWAYS* surround the updates with a critical section.
3) Critical Sections should be very small. Lock it, update it, release it.
You can have a "deadly embrace" otherwise. And these are hard to debug.
4) Dont over do it. To many threads gets hard to handle, complicated and doesnt perform well.
5) Starting a thread nicely is easy. Terminating it is much harder to do!
But terminating nicely is important.
6) Do it "Right" right from the git go. Do not slap the code together expecting to come back later and clean things up. Actually, this is a good one for ANY programing! But it applies 10x as much in a multi-threaded environment.
These issues are not hard to deal with. But they must be dealt with or your app will become very unstable.
"The greater danger for most of us is not that our aim is too high and we miss it, but that it is too low and we reach it."
On Wed, Mar 3, 2010 at 12:32 PM, James H. H. Lampert < jamesl@xxxxxxxxxxxxxxxxx> wrote:
Bruce Vining wrote:
Yes, I'm familiar with threads and multi-threaded jobs :)
Any recommendations on where to start relieving my own ignorance (and
please, no sarcastic links to "lmgtfy.com")?
How difficult are they to deal with? What languages support threads?
At what OS level do they become possible/practical?
This is the C programming iSeries / AS400 (C400-L) mailing list To
post a message email: C400-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
This is the C programming iSeries / AS400 (C400-L) mailing list To post a message email: C400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/c400-l
Capgemini is a trading name used by the Capgemini Group of companies which includes Capgemini Sverige AB, a company registered in Sweden (number 556092-3053) whose registered office is at Gustavslundsv?gen 131 Box 825 - S-161 24 Bromma.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to
read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message
in error, please notify the sender immediately and delete all copies of this message.