|
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 +---
As an Amazon Associate we earn from qualifying purchases.
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.