RE: Multithreaded Programming

I consider a shared user space better because the CPU cycle overhead is
lower and the semantics are cleaner.  I agree that db records and data areas
can be made to work but they include a lot more CPU overhead, may cause
physical disk IO, and the semantics are not exactly like variables shared
between threads.  I also dislike the cost to create a process on an AS/400.
Different strokes.

Richard Jackson
(speaking only for myself)

-----Original Message-----
From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
Behalf Of Rich Duzenbury
Sent: Wednesday, February 28, 2001 4:23 PM
To: RPG400-L@midrange.com
Subject: RE: Multithreaded Programming


Yes, we can spend time discussing the semantic differences between threads
and processes.  Technically, my solution does not directly use threads, but
as you point out, processes.   The work gets done in a similar manner to
the point where it most likely doesn't matter.

As I understand threads in the general sense, they do not have access to
each others variables, with the exception of process global variables and
thread global variables.  At least that's how they work on other platforms
I use them on.

I am curious as to why you consider a shared named user space 'better' than
a data area or database record for sharing data between threads (er,
processes as you point out)?  Data areas and database records have some
excellent pluses.  They are supported by the operating system back at least
as far as S/38.  It is quite easy to have OS/400 be an effective 'gate
keeper' by using the data area and record 'lock' mechanisms to synchronize
access to shared information.  They are very easy to implement, and (most
important, IMO) most programmers already understand them.

Regards,
Rich

At 01:49 PM 2/28/01 -0600, you wrote:
>A strict interpretation of multithreading means that the threads have
access
>to each other's variable storage in memory.  Obviously there are controls
on
>this sharing.  Your description below is for multi - processes and multi -
>threads.  Separate processes cannot access each other's variables.  It may
>not matter to the original requester - but then again it might.  If you use
>separate processes and you want them to share global data, I submit that a
>shared named user space would be a better solution.  There is a "compare
and
>swap" or "test and set" function to control concurrent updating.
>
>Richard Jackson
>(speaking only for myself)
>
>-----Original Message-----
>From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
>Behalf Of Rich Duzenbury
>Sent: Wednesday, February 28, 2001 10:42 AM
>To: RPG400-L@midrange.com
>Subject: Re: Multithreaded Programming
>
>
>The simplest multithread mechanism I know of is SBMJOB!  Each job can wait
>indefinitely for it's parameters (using little system resources) by waiting
>for a data queue message.  The parent can then signal the child to start
>processing by sending a message to the data queue.  Once the thread is
>complete, the child can end, or if you like go back to waiting for another
>message.  Global data can be safely shared in a data area or a database
>record - you just have to be sure to watch your locking.
>
>Regards,
>Rich
>
>At 04:02 PM 2/28/01 +0000, you wrote:
> >Hi All,
> >
> >I need some help on creating an application(RPG/CL) which can use
> >multithreads while running the job.
> >Can anyone give me some direction with examples.
> >
> >thanks in advance,
> >Ray.
> >_________________________________________________________________
> >Get your FREE download of MSN Explorer at http://explorer.msn.com
> >
> >+---
> >| 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
> >+---
>
>Regards,
>Rich
>
>+---
>| 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
>+---
>
>+---
>| 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
>+---

Regards,
Rich

+---
| 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
+---

+---
| 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
+---