|
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 +---
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.
midrange.com
