Are class properties thread safe in delphi?

Question

I would like to use my own class with a few properties. I can use read and write to customize how and which (e.g.) private variable to write or read.

An example would be an Integer (MyInteger) in this class:

type
  TMyClass = class
  private
    MyInteger : Integer;
    function SomeFunction : Integer;
  public
    property TheInteger : Integer read SomeFunction write MyInteger;
end;

Would it be safe if (e.g.) the class would constantly access (read) MyInteger while another thread accesses TheInteger (write) from another thread of the current instance?

Hope you guys know what I mean... Basically I don't know if it's safe in general if multiple threads accesses a var in memory at the same time... (without Critical sections)

EDIT:

Would there also be a difference between this class:

type
  TMyClass = class
  private
    MyInteger : Integer;
    function SomeFunction : Integer;
  public
    property TheInteger : Integer read MyInteger write MyInteger;
end;

and this:

type
  TMyClass = class
  private
    function SomeFunction : Integer;
  public
    MyInteger : Integer;
end;

?

Answer 1

The place where a variable is located does not imply any kind of thread safety. These are two completely different concepts.

What makes a variable thread safe or not is the way you manage access to it.

E.g., this would be thread safe, because the only way to manipulate FMyInt is through one of the three methods, which are all implemented in a thread-safe manner:

type
  TMyClass = class
  strict private
    FMyInt : Integer;
  public
    procedure IncrementValue;
    function QueryValue : Integer;
    function SubtractValue( aWhat : Integer) : Integer;
  end;

procedure TMyClass.IncrementValue;
begin
  InterlockedIncrement( FMyInt);
end;

function TMyClass.QueryValue : Integer;
begin
  result := InterlockedExchangeAdd( FMyInt, 0);
end;

function TMyClass.SubtractValue( aWhat : Integer) : Integer;
begin
  result := InterlockedExchangeAdd( FMyInt, -aWhat);
end;

And so would this, but less efficient. Interlocked is not suitable for everyting so it really depends on the use case what method should be used.

type
  TMyClass = class
  strict private
    FMyInt : Integer;
    FLock : TCriticalSection;
  public
    constructor Create;
    destructor Destroy;  override;
    procedure IncrementValue;
    function QueryValue : Integer;
    function SubtractValue( aWhat : Integer) : Integer;
  end;

constructor TMyClass.Create;
begin
  inherited;
  FLock := TCriticalSection.Create;
end;

destructor TMyClass.Destroy;
begin
  FreeAndNil( FLock);
  inherited;
end;

procedure TMyClass.IncrementValue;
begin
  FLock.Enter;
  try
     Inc(FMyInt);
  finally
    FLock.Leave;
  end;
end;

function TMyClass.QueryValue : Integer;
begin
  FLock.Enter;
  try
    result := FMyInt;
  finally
    FLock.Leave;
  end;
end;

function TMyClass.SubtractValue( aWhat : Integer) : Integer;
begin
  FLock.Enter;
  try
    Dec( FMyInt, aWhat);
    result := FMyInt;
  finally
    FLock.Leave;
  end;
end;

Note that the same works, if I put the values into a record and have a bunch of functions and procedures doing the manipulation. The place where the variable(s) is/are stored, does not matter.

Do's & Dont's

Never mix different kind of locks. For example, mixing Interlocked-Functions with TCriticalSection, or mixing TCriticalSection with TMutex, or mix any kind of locks with completely unguarded access. Doing so would be a recipe for failure, because the different kinds of locks do not know each other.

Keep in mind that most lock mechanisms are only logical locks, which do not really prevent you from doing something insane with your data. It is therefore a good approach to encapsulate access to the data as much as possible to keep control.

Answer 2

you ask if there is any difference in terms of thread safety between:

type
  TMyClass = class
  private
    MyInteger : Integer;
  public
    property TheInteger : Integer read MyInteger write MyInteger;
end;

and:

type
  TMyClass = class
  public
    MyInteger : Integer;
end;

There is no difference at all. The compiler generates identical code for both variants. The compiler inserts no synchronization code at all.

In fact, in no circumstances does the compiler ever insert thread synchronization code. Certain library functions have thread synchronization, for instance TInterfacedObject._AddRef etc., but the compiler itself never writes synchronization code. The onus always falls on your the programmer to deal with thread safety.

---

For a more concrete example, let's look at the specific code in your question.

Your shared variable is an integer. So long as the integer is aligned, that is it is stored on a 4 byte boundary, there can never be tearing. A read access can never observe a partial write.

Your scenario is that of a single write thread, and multiple read threads. You specify no extra ordering constraints. With these facts and constraints in place, there is no need for any locking whatsoever. Any data races must be benign, and the lock free code is semantically indistinguishable from code using locks or interlocked access.

When do you need to synchronize access?

• If you have multiple write threads, you need to synchronize access.
• If your variable is not aligned, or wider than a pointer, then you need to synchronize.