Re: Portable memory barrier?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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 <something> algorithm
> because Ada doesn't provide any portable <blah> operations". Along with an
> explanation of the <something> 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