RE: Multithreaded Programming

This sounds like performance vs simplicity.  I agree with you in the case 
where you must create hundreds or thousands of threads, but in the 'small' 
case of needing a thread or three, I prefer the simple multi process 
approach, especially since it applicable to so many more operating system 
levels.

I don't know much about 'shared user spaces', but due to the single level 
storage nature of the AS/400, it seems they may also cause physical disk IO.

Regards,
Rich

At 11:06 AM 3/1/01 -0600, you wrote:
>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
>+---

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