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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,8e11100f675ea2df X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.66.72.232 with SMTP id g8mr7546863pav.23.1357417528873; Sat, 05 Jan 2013 12:25:28 -0800 (PST) Path: 6ni85295pbd.1!nntp.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail NNTP-Posting-Date: Sat, 05 Jan 2013 14:25:26 -0600 Date: Sat, 05 Jan 2013 12:19:02 -0800 From: Charles Hixson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: asynchronous task communication References: <1c2dnd5E6PMDR33NnZ2dnUVZ_sednZ2d@earthlink.com> <50e18094$0$6583$9b4e6d93@newsspool3.arcor-online.net> <7NednS4s2oukfXzNnZ2dnUVZ_oadnZ2d@earthlink.com> <7cudnYloBfQDw3_NnZ2dnUVZ_rKdnZ2d@earthlink.com> <50e5755c$0$9517$9b4e6d93@newsspool1.arcor-online.net> In-Reply-To: <50e5755c$0$9517$9b4e6d93@newsspool1.arcor-online.net> Message-ID: <4OCdnRkrDcOrEXXNnZ2dnUVZ_q2dnZ2d@earthlink.com> X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 216.244.16.210 X-Trace: sv3-rgMX60uAxdztaN9I7CZnAsrT55Djl0xr5l5Qv0lyzX9EBhDuq8e9sWU7GhjLHc48i7HgCbbpIZP4Gc+!71es+NOgDq4FG1/OjJ+72RmFUgOnKSS9VYMZVwqOK1ApE5RADU8e8I2M/KiIsgglJBQ2OYFoTJtW!kbi5BZYZYx6O2kmtMjUq2A== X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 4865 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2013-01-05T12:19:02-08:00 List-Id: On 01/03/2013 04:11 AM, Georg Bauhaus wrote: > On 03.01.13 02:30, Charles Hixson wrote: >> I guess a part of the question is "What is the overhead on a protected >> variable?". If it's small, then I'd prefer to have one attached to >> every cell, as it eliminates one centralized spot of contention, and >> means that slightly simpler messages can be passed. > > Chances are that a protected object employs a locking mechanism > of the OS (at least in a "PC run-time"). This is probably not the > fastest, leanest thing to have. However, I guess you could use > CAS based access to the letter boxes, in particular if the number > of messages is fixed. > > Pat Rogers has illustrated an example, also referred to in Ada > Gems #93 and #98, > http://benchmarksgame.alioth.debian.org/u32q/program.php?test=chameneosredux&lang=gnat&id=2 > > http://www.adacore.com/adaanswers/gems/gem-93-high-performance-multi-core-programming-part-1/ > > Unfortunately, the size is not fixed. I can say that there is one mailbox per cell, but the number of cells is not fixed either. And while I'm planning on limiting the size (capacity) of the mailbox, the largest size is expected to be far larger than the mean size. OTOH, simplifying things is that the mailbox has only one reader, and writers, except the reader, can only append. Also, the reader, "takes possession" of the contents of the mailbox, and replaces it with an empty mailbox. At least that's my current design. I've been contemplating a modified design where the mailbox is "attached" to the cell, and hold both out-going and in-coming messages. There would also need to be a "letter-carrier" that collected and distributed the messages. This would reduce the sync requirements to a boolean flag set and cleared by the mailbox accessors that said whether the mailbox was busy. If it was busy, the accessing task could decide whether to wait a bit or to do something else and the try again. This would require a "clear and set" on the flag, but nowhere else. This modified design appears clearly superior if there are enough tasks that one can be assigned to be the letter-carrier, and I guess that if I arrange it to be inactive most of the time it might work even on my limited system. (Actually the real design would then make the cell logically dependent on the mailbox, as in normal operation the mailbox could control the rolling in of the cell from secondary storage. Perhaps only occasionally would the entire roster of cells be sequentially activated.) This idea for a design modification is because an investigation of sizing constraints shows that the original design it totally impossible on my system. Even this redesigned system may need to be modified so that mailboxes spend much of their time on disk, if I can devise a way to enable this. Perhaps some sort of rolling activation. Virtual memory isn't a plausible answer because the program needs to be able to save its state quickly and shutdown...and then to pick-up where it left off. (But this is getting far away from the original problem of concurrent design, which now looks solved...I've got in hand a design for a CAS based stack, which is all that the mailbox needs, though I need to modify it a bit to "popall" rather than simply "pop".)