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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Portable memory barrier? Date: Fri, 19 May 2017 09:54:12 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <0fc56bf7-1cfa-4776-9c47-a573db315c5f@googlegroups.com> NNTP-Posting-Host: vZYCW951TbFitc4GdEwQJg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:46812 Date: 2017-05-19T09:54:12+02:00 List-Id: On 18/05/2017 23:01, Randy Brukardt wrote: > As I always repeat, the ARG is looking more for problems than for solutions > (we're plenty inventive in that regard). The most useful thing is a problem > statement on the lines of "I can't write a portable algorithm > because Ada doesn't provide any portable operations". Along with an > explanation of the algorithm. > > It's fairly obvious to me that since Atomic only protects a read or a write, > but not both that classic operations like test-and-set can't be (directly) > written using it. Some algorithms can be constructed without test-and-set, > but plenty of others can't be. AFAIK, only FIFO can rely solely on Load and Store. Almost everything else requires test and/or old value in some form. > I'd think that the feature in question needs to be a low-level as possible > so that it can be implemented as efficiently as possible (if a protected > object is needed to implement it, there is no value to the low-level feature > as anyone can -- and should -- use a PO if that is possible). There is no value if it is too low level. You don't get it portable anyway in the sense that there is no guaranty that each target would have an instruction for that. Not even CAS (Store_If_Equal in the generic package outline). Note that some higher-level operations are implementable with CAS. E.g. atomic increment. > I'd have no idea how to implement your generic without resorting to a PO, > which would defeat the purpose. Not at all. The programmer has no idea what would be more efficient to implement atomic increment on the given machine: 1. CAS in a loop 2. OS call (e.g. under Windows) 3. Built-in operation (e.g. in GCC) 4. protected object Even if he knows the outcome is not portable except PO, which you already declared as no runner. The compiler vendor has and can do the right choice and the programmer just does not care what is going behind. > (We recently had this discussion wrt > Suspension_Objects -- they can always be implemented with a PO, but the > entire point was that they ought to be simpler than that. Thus we didn't > make any additional requirements on them and in fact clarified that only one > task is supposed to be calling Suspend_Until_True. The same sort of dynamic > seems to be in effect here.) [OT IMO raw suspension objects have no use whatsoever. What is really required is entry interface for a tagged type so that you could use timed entry calls in the interfaces rather than passing timeout parameter around and handling exceptions later: select Driver.Queue (IO_Request); or delay 0.001; -- The device is busy end select; /OT] > Anyway, as I said, I know just enough to be dangerous here. You clearly know > more, so send some comments to Ada-Comment to get a discussion started. Else > it will never make the agenda...and then its pretty certain that no changes > will happen! I hoped to get some input from c.l.a. Maybe nobody cares, or maybe some have other and better ideas, use cases etc. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de