[M3devel] readonly access to a BOOLEAN, unprotected?

[Elmar Stellnberger]

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) := 3; y:= 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 — it is only a compiler directive, not a hardware fence of any kind.
> 
> Indeed, a lock statement is needed here (or some other atomic operation).
> 
> On Feb 14, 2014, at 7:32 AM, Elmar Stellnberger <estellnb at elstel.rivido.de> wrote:
> 
>> Hmm; some <*VOLATILE*> pragma like you have it in C would likely be required.
>> 
>> Am 13.02.2014 22:51, schrieb Rodney M. Bates:
>>> Rd.m3 contains, for example:
>>> 
>>> PROCEDURE Closed (rd: T): BOOLEAN =
>>> BEGIN
>>>   RETURN (rd.closed);
>>> END Closed;
>>> 
>>> Most other procedures in Rd lock rd before doing anything.
>>> 
>>> 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.
>>> 
>>> 
>>> 
>> 
>