Leaderboard

You should backup the installation ISO for every Delphi you use before you let the subscription expire. Also it could be problem to bump up the registration limit if you don't have an active subscription - a solution could be to install Delphi to a virtual machine.

Done

The reason for expanding number of threads is to avoid deadlock with nested TParallel.For loops. If you want to use old behavior then you should set UnlimitedWorkerThreadsWhenBlocked to False on each ThreadPool you are using, including the default one. For any other issues you mention, there is nothing we can do if you don't provide details about your code and implementation of your parallel loop mechanisms. While it is always possible that there are other bugs in System.Threading, it is also quite possible that your code has bugs, too. Just because you get access violation in Delphi RTL code, that does not mean that the cause is not in your code. For debugging multithreaded applications, especially the ones that spawn many threads, it is more suitable to use logger and inspect code behavior through logs instead of using debugger. Debuggers are usually too intrusive for multithreaded debugging that involves more that few of background threads as it severely impacts timing.

Delphi: Only the subscription expires. The license remains valid.

This is for C++ Builder PRO TERM LICENSE https://www.embarcadero.com/products/cbuilder/product-editions Delphi doesn't even have such option.

Okay then. I doubt you will have any luck with getting this resolved unless you can provide additional details - which will require an effort on your part. Also, Embarcadero doesn't run this forum and probably doesn't follow what goes on here. If you want them to take notice of the problem you will have to report it to them (which isn't possible at the moment).

Oops, Sherlock. Sorry. Fixed.

It's probably smart to inform about the whereabouts and remote working possibilities. Personally, I would not submit a resume to an "anonymous" position.

We were pleased to hear that version 12.0 addressed the deadlock issue. However, we've encountered three major issues since upgrading: 1. Unfortunately, we've observed a 40% performance decrease with the updated threading.pas in version 12.0, which is unacceptable for our needs. The root of the problem appears to be the ThreadPool growing beyond the max workers we set in our custom TThreadPool. This necessitates the creation of new copies for the new thread within TParallel (we manage necessary copies dynamically using a Dictionary with TThreadID as key). The issue in threading.pas seems to stem from this property being explicitly set to true in TThreadPool.Create: constructor TThreadPool.Create; begin inherited Create; // Initialization code FUnlimitedWorkerThreadsWhenBlocked := TRUE; // More initialization code end; despite already having a default value or having been set to False: property UnlimitedWorkerThreadsWhenBlocked: Boolean read FUnlimitedWorkerThreadsWhenBlocked write FUnlimitedWorkerThreadsWhenBlocked default True; This leads to the TThreadPool.TThreadPoolMonitor.GrowThreadPoolIfStarved procedure unnecessarily increasing the number of worker threads. When I added debugging, I noticed it enters the else if FThreadPool.UnlimitedWorkerThreadsWhenBlocked block multiple times per TParallel.for loop. 2. In previous versions of Delphi, we encountered access violations when closing the debugger if we used TParallel.For without modifications (with the default thread pool). Switching to custom thread pools mitigated this issue, but with version 12.0, the problem seems to persist regardless. The access violation in 12.0 (using a custom thread pool) often occurs here: procedure TThreadPool.TThreadPoolMonitor.Execute; begin // Procedure code Signaled := FThreadPool.FMonitorThreadWakeEvent.WaitFor(TThreadPool.MonitorThreadDelay) = TWaitResult.wrSignaled; // More procedure code end; I've also seen it happen on different lines within the same procedure. We can only reproduce this in our VCL application. Our DUnit test project does not have the same issue 3. With the debugger attached, any operation involving TParallel.For runs excruciatingly slow—about 8-10 times slower compared to twice as slow in version 11.3. For full disclosure and additional information we're using https://github.com/pleriche/FastMM5 but none of my reported issues change with it. The base runtime just becomes a lot slower with it, because the built in FastMM4 doesn't do great with our workload. We're reaching out for insights or solutions to these issues, as the current performance and stability impacts are significant for our projects.