[M3devel] readonly access to a BOOLEAN, unprotected?

[mika at async.caltech.edu]

Yes the unlock I think will have to flush all writes from that processor.
No need to flush the entire cache, any reasonable cache system will track
which lines are modified and flush only those.

Intel processors have a lot of hardware for cache-coherence built in, most
of it just happens automatically in the background.

On Alpha I think you'd have to insert a Memory Barrier (MB) instruction
where the processor releases the lock.

The requirements on the compiler will be different from architecture
to architecture.

Ah there's a nice graphic here:

http://en.wikipedia.org/wiki/Memory_ordering

     Mika

Elmar Stellnberger writes:
>Sorry, I did not get the point about it yet.
>Even if the boolean is read by multiple mem-read operations at least one =
>of them will yield a value # 0 if the boolean was set at that specific =
>sub-operation which should  totally suffice; i.e. if there are four read =
>operations to be done and the forth may read a value # 0 then it should =
>be sufficient that the fourth read is atomic by itself ignoring all =
>other reads and writes except the fourth because booleans are always =
>either zero or one and thus only one byte will matter so that atomic =
>access is ensured.
>Similarely, what difference on caching will a lock yield?
>The lock statement is not associated with the value it protects in any =
>way so it can not explicitly flush the cache for the given value. =
>Theoretically it could choose to invalidate all caches (horribly =
>inefficient!). Well; I think we may have caught the point here. Either =
>way I would expect some kind of machine-level reasoning about it.
>
>Shouldn`t there be a way to atomically access a word on every kind of =
>machine architecture?
>Why not introduce anything like ATOMIC(x) :=3D 3; y:=3D ATMOIC(x); =
>INC(ATOMIC(x),3)
> which should then yield sth. like
>LOCK MOV EAX,[EA]
>LOCK MOV [EA],EAX
>LOCK ADD/INC [EA], const/
>on Intel platforms f.i. and respective machine instructions on other =
>platforms.
>
>Isn`t it horribly inefficient having to lock even for a boolean value?
>Do you think there is any way to achieve ATOMIC(designator) behavior for =
>m3gcc?
>
>
>Am 14.02.2014 um 15:38 schrieb Antony Hosking:
>
>> volatile in C is next to useless on multi-processors =97 it is only a =
>compiler directive, not a hardware fence of any kind.
>>=20
>> Indeed, a lock statement is needed here (or some other atomic =
>operation).
>>=20
>> On Feb 14, 2014, at 7:32 AM, Elmar Stellnberger =
><estellnb at elstel.rivido.de> wrote:
>>=20
>>> Hmm; some <*VOLATILE*> pragma like you have it in C would likely be =
>required.
>>>=20
>>> Am 13.02.2014 22:51, schrieb Rodney M. Bates:
>>>> Rd.m3 contains, for example:
>>>>=20
>>>> PROCEDURE Closed (rd: T): BOOLEAN =3D
>>>> BEGIN
>>>>   RETURN (rd.closed);
>>>> END Closed;
>>>>=20
>>>> Most other procedures in Rd lock rd before doing anything.
>>>>=20
>>>> Even though it's only read access, and to a BOOLEAN, is it really =
>true that we can rely
>>>> on this to work on all targets with neither a lock nor some atomic =
>operation?
>>>> It seems to me like it should be OK, but I have thought that several =
>times before.
>>>> only to be shown wrong.  Meanwhile, modern hardware keeps adding =
>more complex
>>>> caching, making these things trickier.
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>=20