I have seen some time ago people discussing about the new multithreading in Delphi XE and about the fact that Delphi has some \'native\' problems because of the way it implement
I think the "native" issues you are talking about are not related to the way TThread
is implemented, but to other aspects of the RTL:
string
and dynamic arrays) are implemented with an asm lock
opcode to have atomic reference counting (InterlockedDecrement/InterlockedIncrement in x64), which may also scale badly on multi-threaded applications (that is, all cores freezes when this opcode is executed - even if newer CPUs made progress about this, an RCU implementation may scale better).Those weakness are common to all multi-thread libraries - even OTL will suffer about this. They do exist since very early Delphi versions, and are still there with Delphi XE2. The 64 bit implementation is similar (even slower), and the Mac OS platform shares the very same implementation.
Please see this other SO question about how to write scaling multi-threaded applications in Delphi.
To be honest, both points above will appear only on some very specific kind of applications.
So there is nothing to worry about multi-threading in Delphi, if you know those points, and do not abuse of memory manager calls or string process in your threads.