VCL Threading – Synchronization

Although I am using Oxygene a lot these days, Delphi remains my tool of choice for Win32 (and x64) development, together with the VCL. Hence this post. A long time ago, in a galaxy far far away, Delphi was a Windows only development tool. 16 was the number of the bits with which it was concerned, and 1 was the number of threads in the process (though it was not called a thread). It was a simpler time. Then the bits were doubled and the number of threads did multiply, but it was important still that some things happened only on the original thread, though for a time a blinded eye could be turned since – no matter the plurality of threads – with only one piece of silicon to share, only one thread could be running at any one time. Yet lo, TThread.Synchronize() was conceived.

Of Threads, Stacks and RAM – Part 2

In the previous post in this series, we saw that the number of threads that a given process could support was determined by a number of factors, of which the stack size reserved for each thread was key. We also saw how we could change the stack size used by our application and how this could increase the number of threads that our process could support. But if you thought it seemed a bit crude to have to set a single stack size for all the threads in a process (including the main thread), then you would be right, and we can do something about this.

Commitment Issues

No, not a relationship blog and no, not a rant about the relationship between Embarcadero and the Delphi community. ┬áThis is a strictly and purely technical post about what “Committed” means in terms of Windows memory, and in particular a key aspect of how that applies to threaded applications.