1

I have a task where I have to do some heavy CPU/RAM stuff to do. With the outcome of that, I have to do some database requests. All of this I have to do for some thousand times, so I'm doing it inside a background thread. Now I'm considering dividing each task up into the two parts and split them between 2 separate threads, so that the first thread don't have to wait for the database requests to finish. It then could do the CPU/RAM stuff for the second round while the second thread is waiting for the database requests of the first round and everything would speed up.

Now, is it safe to instantiate the second TThread descendent from within the first one? Or do I need to instantiate TThread descendents from within MainThread? I could do both, but instantiating the second from within the first would be easier in my case, and it would be following the oop paradigm as the second thread would be transparent to the rest of the program.

Cœur
  • 37,241
  • 25
  • 195
  • 267
RSE
  • 322
  • 1
  • 10
  • 5
    It is perfectly safe. – TLama Oct 17 '14 at 09:04
  • I don't see why would it be an issue. – mg30rg Oct 17 '14 at 09:04
  • 1
    I'm just never assuming that VCL stuff is thread safe, and TThread is so complex that I was just too lazy to examine thread safety of it myself. Also, that would have been much more error prone due to the sheer complexity of TThread. – RSE Oct 17 '14 at 09:11
  • Most of the VCL components are not thread-safe because they originate before the preemptive multitasking era when thread safety was no real issue. TThread and other threading components on the other hand were - obviously - designed with preemptive multitasking in mind. – mg30rg Oct 17 '14 at 09:30
  • 1
    The VCL is irrelevant. TThread is not a VCL component. The lack of thread safety of the VCL is nothing to do with when it was designed. It is inherited from the underlying framework which is Win32. Now Win32 is threadsafe, but windows have affinity with the thread that created them. Input queues are thread oriented. So the Win32 GUI framework leads you to all Win32 GUI code running in the main thread. The VCL just inherited that. – David Heffernan Oct 17 '14 at 10:47
  • @DavidHeffernan - Wow! I always thought VCL is not (always) thread safe because it was designed in the ancient Win16 times for cooperative multitasking. But it really makes sense in your point of view too. – mg30rg Oct 17 '14 at 11:12
  • @mg30rg Win16 had no threads so in those days thread safety was a non-issue. When Win32 came along and the VCL moved to Win32, the VCL designers did what was natural on top of the Win32 platform. I doubt that designers starting today could design a very useful multi-threaded VCL. – David Heffernan Oct 17 '14 at 11:14
  • @mg30rg - VS has exactly the same issues. Call methods on visual components from non-GUI thread? - you have to Invoke/BeginInvoke them, (AKA SendMessage/PostMessage). – Martin James Oct 17 '14 at 11:14
  • 1
    @MartinJames That's .net rather than VS to be pedantic. And WinForms in particular. Which has a very similar design to the VCL. WPF is a little different though and is more forgiving. – David Heffernan Oct 17 '14 at 11:16
  • If it was not for David Heffernan's comment I would not even know what you are saying. I mean for me VS means MSVC++ if not stated otherwise and in MSVC++ sending a message is a pretty normal way to communicate with a form. – mg30rg Oct 17 '14 at 11:52
  • 2
    @RSE: VCL = *Visual Component* Library. TThread is part of the RTL (*Run Time* Library). VCL is not thread safe, RTL is unless indicated otherwise in the documentation. – Ken White Oct 17 '14 at 17:30
  • @ken thanks for this hint. I just didn't think that much about whether TThread is VCL or RTL. Knowing that RTL is thread safe I would have. I didn't know this big difference between VCL and RTL regarding thread safety. – RSE Oct 18 '14 at 11:19

1 Answers1

4

I did it lots of times in production code and it never was a real issue. I can say it seems to be perfectly safe.

mg30rg
  • 1,311
  • 13
  • 24