0

Can I add items in a Generic list or dictionary only in the unit initialization and then use it as read-only for multiple threads?

I read in a topic that TList<T> is thread safe and in another topic that TDictionary<T> is not. What would be the difference between the two?

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
Paulo César Botelho Barbosa
  • 29
  • 1
  • Have you view this question? https://stackoverflow.com/questions/27517063/delphi-is-tdictionary-thread-safe – John Easley Aug 12 '17 at 17:27
  • Thank you very much for responding. I saw yes, however my question is if I initialize the dictionary items in the "initialization" of some unit and use it only for reading in multiple threads is safe. – Paulo César Botelho Barbosa Aug 12 '17 at 17:35

1 Answers1

3

Reading is safe, Writing is not. As long as you can ensure the TList/TDictionary is populated before any threads access it, and you are only retrieving items, never adding/modifying items, then it is safe. However, it is best to not rely on that behavior. You should always be explicit in syncing access to shared resources across threads, such as with TCriticalSection, TMutex, TMREWSync (or Win32 SRW locks), TMonitor, etc.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • 1
    If performance matters then you want to avoid locks. So it is best to rely on read only thread safety. – David Heffernan Aug 12 '17 at 20:46
  • @David, it is not said any of the them is thread safe for reading only. It's the internal implementation. You can read the source and say it is. But one day EMBT changes the implementation and you'll be surprised. – Victoria Aug 13 '17 at 13:24
  • @Victoria That's fair. But in a multi threaded performance sensitive environment, locks are to be avoided so if you can't trust these classes then you'd implement your own. – David Heffernan Aug 13 '17 at 13:30
  • @David, I did that already. Thread unsafe ones are using efficient locks (slim RW or CS, if any, they learn that :) It's easy, if you allow them to be "auto-learning" (which is at compile time, and if allowed at runtime), they're checking what thread(s) are doing. If all of them is only reading and only one was trying to write so far, slim RW lock is used. If more than one thread has tried to write, I upgrade the lock to CS. – Victoria Aug 13 '17 at 14:53
  • @Victoria That will perform worse than an unprotected collection the this read only scenario. – David Heffernan Aug 13 '17 at 15:22
  • @David, you meant _than_. But, yeah, but that's a consequence of unbelief. But I can control it at compilation time, so as at runtime (variants of thread safe and non thread safe dictionary interface implementations). – Victoria Aug 13 '17 at 15:34
  • @Victoria I suppose my view is that Emba give no threading guarantees at all about any of their libraries, so you kind of have to rely on knowledge of the implementation. – David Heffernan Aug 13 '17 at 15:39
  • @David, that's what I agree with. Just when we switched from non generic collections to generic ones, we made this decision (to make it for us more explicit). We now know which of our custom classes instantiate for which purpose with a guarantee that it will be or not be thread safe. Btw. a similar situation is in .NET as well, for example. – Victoria Aug 13 '17 at 15:57