atomic setting of a double variable

[Lars Fosdal 1792]

12 hours ago, David Heffernan said:

Gonna be hard to implement an atomic increment without using a var parameter.

 

Perhaps if people want to talk about the issue of whether certain variables are aligned, then perhaps a new topic would be better. 

Someone should author the definitive article on the memory alignment of variables. 
Which ones always are?
Which ones may not be, and how to fix it?

Which ones, if any, are out of your control?

[David Heffernan 2347]

1 hour ago, Marat1961 said:

Due to the causal relationship, it seemed logical to me to discuss here.
1. The atomicity of the data assignment operation is ensured if the data is aligned on the double word boundary.
2. The data is aligned if ..

Perhaps you'd like to explain how you go about implementing an atomic increment function without using a var parameter. Which seems to be what you are advocating. 

[Vandrovnik 214]

12 minutes ago, Lars Fosdal said:

Which ones may not be, and how to fix it?

 

type tTest=packed record
      b: byte;
      d: double;  // not aligned
     end;

var t: tTest;

 

Sometimes I have to use packed record to read old data from files.

Edited February 16, 2021 by Vandrovnik

[David Heffernan 2347]

16 minutes ago, Vandrovnik said:

 

type tTest=packed record
      b: byte;
      d: double;  // not aligned
     end;

var t: tTest;

 

Sometimes I have to use packed record to read old data from files.

I think @Lars Fosdal had in mind a post or article with a definitive statement that exhaustively covers every form of variable. 

Edited February 16, 2021 by David Heffernan

[Marat1961 17]

It seems naive to me to hope that var parameter will be aligned.
At a minimum, I would insert a check 

 

Quote

procedure InterlockedSetDouble(var target: double; Value: double);
begin
  if (@target and $7) = 0 then
    Target := Value
  else
    ...

 

Edited February 16, 2021 by Marat1961

[Lars Fosdal 1792]

1 minute ago, David Heffernan said:

I think @Lars Fosdal had in mind a post or article with a definitive statement that exhaustively covers every form of variable. 

Correct.
Which ones that one can trust to be.
Which ones that can be made to be - and how.
The impossible ones.  
Perhaps even a set of cookbook examples on how to do atomic exchange of different variable types, and what to do if you can't do them atomically due to misalignment.

 

[Marat1961 17]

I also find it interesting to use the function

 

function InterlockedSetDouble(Value: double): double;
begin
  if (@Result and $7) = 0 then
    Result := Value
  else
    ...

 

[David Heffernan 2347]

1 hour ago, Marat1961 said:

It seems naive to me to hope that var parameter will be aligned.

It's called the interface contract. It relies on an agreement between callee and caller, rather than hope.

[Marat1961 17]

Contract programming.

 

The simplest version of the contract is preconditions - requirements that must be met before a specific action.

The method must check the validity of the passed parameters.

 

https://en.wikipedia.org/wiki/Design_by_contract

[Lars Fosdal 1792]

@Marat1961  According to your link

Quote

The DbC approach assumes all client components that invoke an operation on a server component will meet the preconditions specified as required for that operation.

 

Where this assumption is considered too risky (as in multi-channel or distributed computing), the inverse approach is taken, meaning that the server component tests that all relevant preconditions hold true (before, or while, processing the client component's request) and replies with a suitable error message if not.

So, by the general rule

Quote

The method must check the validity of the passed parameters.

is not required, as the caller is responsible.

[Marat1961 17]

I completely agree that this approach has a right to life.

If the client code is written by you, if you never make mistakes.

 

That is, if the target, for example, was allocated on the heap,
if the target is not part of a packed record, etc.

But if you write that your procedure guarantees atomicity (judging by its name).
I think a check will not hurt.

From the point of minimizing the code, it is better to insert checks at the beginning of the procedure.

Well, at least observe the minimum decency and insert Assert into debug mode.

[Stano 143]

Again, only from a wise book. I agreed with that.
Check everyone

• enter the routine (arguments)
• the result sent from the function

[Lars Fosdal 1792]

The check has a performance penalty, so using assert is probably the better option if you must have verification.