Question

so far I thought that any operation done on “shared” object (common for multiple threads) must be protected with “synchronize”, no matter what. Apparently, I was wrong – in the code I’m studying recently there are plenty of classes (thread-safe ones, as the Author claims) and only one of them uses Critical Section for almost every method.

How do I find what parts / methods of my code needs to be protected with CriticalSection (or any other method) and which not?

So far I haven’t stumbled upon any interesting explanation / article / blog note, all google results are:

a) examples of synchronization between thread and the GUI. From simple progressbar to most complex, but still the lesson is obvious: each time you access / modify the property of GUI component, do that in “Synchronize”. But nothing more.

b) articles explaining Critical Sections, Mutexes etc. Just a different approaches of protection/synchronization.

c) Examples of very very simple thread-safe classes (thread safe stack or list) – they all do the same – implement lock / unlock methods which do enter/leave critical section and return the actual stack/list pointer on locking.

Now I’m looking for explanation which parts of code should be protected.

could be in form of code 😉 but please don’t provide me with one more “using Synchronize to update progressbar” … 😉

thank you!

Answer 1

You are asking for specific answers to a very general question.

Basically, apart of UI operations, you should protect every shared memory/resource access to avoid two potentially competing threads to:

• read inconsistent memory
• write memory at the same time
• try to use the same resource at the same time from more than one thread… until the resource is thread-safe.

Generally, I consider any other operation thread safe, including operations that access not shared memory or not shared objects.

For example, consider this object:

type
  TThrdExample = class
  private
    FValue: Integer;
  public
    procedure Inc;
    procedure Dec;
    function Value: Integer;
    procedure ThreadInc;
    procedure ThreadDec;
    function ThreadValue: Integer;
  end;

ThreadVar
  ThreadValue: Integer;

Inc, Dec and Value are methods which operate over FValue field. The methods are not thread safe until you protect them with some synchronization mechanism. It can be a MultipleReaderExclusiveWriterSinchronizer for Value function and CriticalSection for Inc and Dec methods.

ThreadInc and ThreadDec methods operate over ThreadValue variable, which is defined as ThreadVar, so I consider it ThreadSafe because the memory they access is not shared between threads… each call from different thread will access different memory address.

If you know that, by design, a class should be used only in one thread or inside other synchronization mechanisms, you’re free to consider that thread safe by design.

If you want more specific answers, I suggest you try with a more specific question.

Best regards.

EDIT: Maybe someone say the integer fields is a bad example because you can consider integer operations atomic on Intel/Windows thus is not needed to protect it… but I hope you get the idea.