Question

I’m working with a simple static thread pool, where there are 4 threads, each with a queue, that process individual lines from a string list. After each thread has completed one of the requests in its queue, it synchronizes an event, which is handled in the parent thread. This is done by calling DoComplete() after it’s done, like so:

procedure TDecoderThread.DoComplete(const Line: Integer; const Text: String);
begin
  FLine:= Line;
  FText:= Text;
  Synchronize(SYNC_OnComplete);
end;

procedure TDecoderThread.SYNC_OnComplete;
begin
  if assigned(FOnComplete) then
    FOnComplete(Self, FText, FLine); //Triggers event which is handled in parent thread
end;

On the other end, in their parent thread, these events are handled with this procedure:

procedure TDecoder.ThreadComplete(Sender: TDecoderThread; const Text: String;
  const Line: Integer);
begin
  FStrings[Line]:= Text; //Updates the original line in the list with the new text
end;

Since I have 4 different threads, each of which might call this OnComplete() event at the same time as each other, do I also have to worry about thread protecting this FStrings: TStrings? Could two threads triggering their OnComplete() event at the same time cause a deadlock in their parent thread when writing to this string list? Or would the main thread be smart enough to wait until one of them is done before handling the other?

PS – Yes, this little project was an attempt to answer another previous question from someone else here on SO, which has been answered far differently, but in order to get myself a little more familiar with multi-threading, I continued this sample project anyway.

Answer 1

Since the OnComplete event is being triggered by Synchronize(), you do not need to use a thread-safe lock around the FStrings list, since all access to the list is being delegated through the main thread, so only one OnComplete event handler can actually run at a time. If you were not using Synchronize(), you would need such a lock around FStrings if items are being added/removed and thus reallocating the list memory, or if other threads were reading the values from FStrings, while the threads were still running. If the processing threads are the only ones accessing FStrings, there is no risk for concurrent access of the individual items, so no lock would be needed.