From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,8e11100f675ea2df X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.224.198.196 with SMTP id ep4mr19022768qab.3.1356985128826; Mon, 31 Dec 2012 12:18:48 -0800 (PST) Received: by 10.49.84.167 with SMTP id a7mr6051437qez.11.1356985128809; Mon, 31 Dec 2012 12:18:48 -0800 (PST) Path: k2ni4226qap.0!nntp.google.com!ee4no9887514qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 31 Dec 2012 12:18:48 -0800 (PST) In-Reply-To: <7NednS4s2oukfXzNnZ2dnUVZ_oadnZ2d@earthlink.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=69.153.58.182; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 69.153.58.182 References: <1c2dnd5E6PMDR33NnZ2dnUVZ_sednZ2d@earthlink.com> <50e18094$0$6583$9b4e6d93@newsspool3.arcor-online.net> <7NednS4s2oukfXzNnZ2dnUVZ_oadnZ2d@earthlink.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <1c4c3de6-a261-443b-bf23-05a97f974b6a@googlegroups.com> Subject: Re: asynchronous task communication From: Shark8 Injection-Date: Mon, 31 Dec 2012 20:18:48 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-12-31T12:18:48-08:00 List-Id: On Monday, December 31, 2012 12:52:22 PM UTC-6, Charles Hixson wrote: > Thank you for your answer. >=20 > The problem with that solution is that I've been advised that I=20 > shouldn't have many more tasks than available cores, and that uses 2 of= =20 > my available 6. True, several clients could use the same postmaster,=20 > but it's still too resource intensive. I'm rather dubious of this advice -- without any reasoning it reeks of the = "premature optimization" problem. Besides, unless you're making it for a specific [homogenized] computer plat= form (I.E. the PlayStation 2) there's no guarantee that the user will have = the same set-up... further, it restricts you to your particular computer. (= I recently got a new computer, which has a different number of cores than m= y old one... I would not like to be compelled to recompile my programs beca= use of such a minor difference.) > It's looking more and more like protected objects on the heap are the=20 > best answer. I just wasn't sure that a built-in answer didn't exist. Protected objects are pretty nice, so are the Containers (w/ the generalize= d for-loop). But if it's something that logically maps well to TASK, there'= s no reason to avoid TASK -- that is, conform your code to the problem, not= to the details of the executing computer. > OTOH, actual non-blocking (i.e. asynchronous) calls to either threads or= =20 > protected items is what I really need. Ada can do it; I don't have my books available, but I believe asynchronous = select is covered in both: http://www.amazon.com/Building-Parallel-Embedded-Real-Time-Applications/dp/= 0521197163/ref=3Dsr_1_2?ie=3DUTF8&qid=3D1356984746&sr=3D8-2&keywords=3DAda+= Parallel+programming and http://www.amazon.com/Concurrent-Real-Time-Programming-Ada-ebook/dp/B001GS6= TBO/ref=3Dsr_1_3?ie=3DUTF8&qid=3D1356984746&sr=3D8-3&keywords=3DAda+Paralle= l+programming Or just go to the RM: http://www.ada-auth.org/standards/12aarm/html/AA-9-7-4.html > These other things are make-shift kludges. They centralize control that = should be distributed.=20 Hm, then should you be looking at the DSA? -- Or is that a different 'distr= ibuted' than you are talking about?