Simple multithreading code example in Free Pascal

[marcov]

Dariusz Mazur posted a lockless queue once called FLQueue. There was some discussion if it was only ok on systems with in order memory storing. ( afaik x86/x86_64 except for some extreme big iron)

[Epand]

This creates a new thread, it does not send a message to an existing worker thread as asked

After having looked into the hints posted today, I didn't find what meets my need - please feel free to grumble about that and to tell me that I have overlooked someting.
It's more or less that what Warfley expressed, a working/computing thread shall be able to signal an other multi thread. I'll try to explain it a bit.

Please think of this:
There will be one main thread,
and there will be e.g. 5 multi threads (that number only as an example, may be much more).
The main thread creates the multi threads and after their creation they will have to be in suspended mode,
then the main thread does start all multi threads: every multi thread shall be waiting for a signal before going ahead,
then the main thread signals the first of the multi threads to go ahead,
when the first multi thread has done certain steps then he signals the second one to go ahead, and the first one concurrently goes ahead with other computations,
when the second multi thread has done certain steps then he signals the third one to go ahead, and the second one concurrently goes ahead with other computations,
...and so on until the penultimate multi thread has signalled the last one.

May be now it's a bit clearer what the program shall achieve.
The mechanism itself is not the problem, it's the realization of the above to keep it as simple as possible.

[Warfley]

Then you might consider using Events: https://www.freepascal.org/docs-html/rtl/system/rtleventcreate.html (this and the 4 functions in the "See also" are all you need)

[avk]

If only to follow exactly the description of the problem, it seems that the Events here are redundant(if I understand the problem correctly, of course).
Wouldn't this do the trick?

Code: Pascal  [Select][+][-]

1. type
2.   TMyThread = class(TThread)
3.   private
4.     FNext: TMyThread;
5.   protected
6.     procedure Execute; override;
7.   public
8.     constructor Create(aNext: TMyThread);
9.   end;
10.  
11. procedure TMyThread.Execute;
12. begin
13.   //some steps
14.   if FNext <> nil then
15.     FNext.Start;
16.   //some other steps
17. end;
18.  
19. constructor TMyThread.Create(aNext: TMyThread);
20. begin
21.   inherited Create(True);
22.   FNext := aNext;
23. end;
24.  
25. procedure RunThreads;
26. var
27.   Pool: array[1..5] of TMyThread;
28.   Prev: TMyThread = nil;
29.   I: Integer;
30. begin
31.   for I := 5 downto 1 do
32.     begin
33.       Pool[I] := TMyThread.Create(Prev);
34.       Prev := Pool[I];
35.     end;
36.   Pool[1].Start;
37.   //some other actions
38. end;
39.  

[SymbolicFrank]

When you have multiple threads that read/modify the same things and have to wait for completion, it is often faster to do it serial, in one thread or the main program. You need to do things as asynchronous as possible.

The optimal way to use threads is by giving them all self-contained tasks. You need (at least) two queues: one to post jobs and one for the results. You could spawn a new thread for each task, but there is an optimal number and with a queue, not only the main program can post jobs, but threads can do that as well. That way, you can do searches and rendering by partitioning the data.

Look at the PS3 CPU. You use DMA to copy the data (and optimally the code as well) needed to a CPU, have it run the task and use DMA to move the data back to main memory. Unfortunately, most multi-core CPU's (except microcontrollers) don't have local storage (although they partially use their cache for that and have shadow registers), so keeping the memory regions separate is important. Basically: don't use pointers, but make a copy of all the data.

That sounds like a lot of extra work, but it is definitely the best way to utilize your CPU for 100%.

[Epand]

Dear freepascal specialists
Please excuse me that I didn't answer earlier. I think to give you a better idea how, in fact, the multi threads interact, it would be helpful to present you a little drawing of the involved thread mechanism. I hope that I'll have it at the end of the next week - until then.

[Thaddy]

What you are missing is probably waitfor.... Anyway threads that interact (except for the main thread) is bad design because you will loose most of the benefits of using threads. IOW then you should not use them at all.

[Epand]

Anyway threads that interact (except for the main thread) is bad design

May be with "interact" I have used a more or less wrong word, a more reasonable expression would be: "...how, in fact, the multi threads signalize among one another in a special way" - that signalizing among one another (the way it is designed) never reaches a deadlock. The drawing of the thread mechanism will make that clear next week.

because you will loose most of the benefits of using threads. IOW then you should not use them at all.

Depending on how the data are processed, there will be benefits. A picture is worth a thousand words, please be so nice to wait for the drawing next week.

[engkin]

"Expand" question should be in a separate thread. His question is not related to this old 2018 thread.

[engkin]

A picture is worth a thousand words, please be so nice to wait for the drawing next week.

Kindly, be nice and post it in a new thread.

[Epand]

"Expand" question should be in a separate thread. His question is not related to this old 2018 thread.

Kindly, be nice and post it in a new thread.

Okay, okay, I'll do so within the next days.

[MarkMLl]

Also you'll get more enthusiasm if you first make some attempt to solve the problem yourself, rather than pretending you're a systems analyst who has minions to decipher his dataflow diagrams.

Multithreading isn't difficult with the support provided by Delphi/Lazarus, but it does need a certain discipline.

The fundamental rules are that (a) nothing should suspend the foreground thread since that will glitch the UI and (b) the background thread should not attempt to interact directly with the UI.

MarkMLl

[Epand]

Also you'll get more enthusiasm if you first make some attempt to solve the problem yourself,

You cannot know that I have alread tried this. Nevertheless sometimes it's possible to simplify and/or to improve programmed algorithms.

rather than pretending you're a systems analyst who has minions to decipher his dataflow diagrams.

I never pretended such nonsense and it never should have been understood that way. You expressed yourself in an impolite manner, try to get more polite before commenting other remarks.

[LV]

Hi!

I decided to give multithreading a try in Free Pascal for some computational physics problems, like the Euler or Navier-Stokes equations. Surprisingly, it went pretty smoothly and I got a noticeable speedup in the calculations. But here's the thing - my code (1) makes sure that no two threads write to the same element of array, but (2) there's still a chance (albeit a small one) that two threads will read the same array value. Is that a safe thing to do? Or should I avoid it with a bit more effort?

Thanks.

[MarkMLl]

I decided to give multithreading a try in Free Pascal for some computational physics problems, like the Euler or Navier-Stokes equations. Surprisingly, it went pretty smoothly and I got a noticeable speedup in the calculations. But here's the thing - my code (1) makes sure that no two threads write to the same element of array, but (2) there's still a chance (albeit a small one) that two threads will read the same array value. Is that a safe thing to do? Or should I avoid it with a bit more effort?

Necroposting is generally discouraged, but since this looks like a minor infraction: I'd suggest that the safety of reading depends on the granularity with which you're protecting your writing.

To say that I'm rusty at this kind or analysis in an understatement, but assuming that you're breaking a big array into tiles: rather than protecting individual elements (using a critical section or whatever), can you ensure that the row or column at a tile border is protected so that the CPU (aka core) processing the adjacent tile will never see anything inconsistent? Or can you marshal your CPUs so that they process the problem in a sufficiently sparse pattern that references never overlap?

Some of this might be OS-dependent (so that you can determine the number of worker CPUs etc.) or might require additional synchronisation primitives (e.g. when a CPU reaches the end of a row).

MarkMLl