× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I don't agree.

If the subroutines do not use some kind of concurrency control, there is no
mechanism to serialize access to the variables.  In other words, if two
threads in the same process execute the code at the same time and the
initial state of the static variables is given, the final variable state is
not defined.

If the code is being executed in two separate jobs, each job has its own
copy of the variables - there are two sets of variables and the variable
states are defined but not common.

Are we talking about the same thing?

Richard Jackson
(speaking only for myself)

-----Original Message-----
From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
Behalf Of Jim Langston
Sent: Wednesday, February 28, 2001 2:31 PM
To: RPG400-L@midrange.com
Subject: Re: Multithreaded Programming


Actually,

I think building subroutines in a library with static variables would
do the same thing as a shared named user space.

Just a though.

Regards,

Jim Langston



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.