Jump to content
dummzeuch

atomic setting of a double variable

Recommended Posts

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?

Share this post


Link to post
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. 

Share this post


Link to post
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 by Vandrovnik

Share this post


Link to post
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 by David Heffernan

Share this post


Link to post

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 by Marat1961

Share this post


Link to post
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.

 

Share this post


Link to post

I also find it interesting to use the function

 

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

 

Share this post


Link to post
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.

Share this post


Link to post

@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.

Share this post


Link to post

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.

Share this post


Link to post

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

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

Share this post


Link to post

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

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×