Posts

Overprotecting multithreaded code

-
Running long tasks in a background thread to keep the UI responsive is one of the main purposes of multithreading. A common code pattern for doing so would look like: procedure TMainForm.BtnClick(Sender: TObject); begin TThread.CreateAnonymousThread( procedure begin DoSomeWork; end; end).Start; end; However, such code often needs to show the results of that long work to the user. Working with the GUI from a background thread is not thread-safe, so such code should be executed in the context of the main thread: procedure TMainForm.BtnClick(Sender: TObject); begin TThread.CreateAnonymousThread( procedure begin DoSomeWork; TThread.Synchronize(nil, procedure begin ShowResults; end); end; end).Start; end; Because ShowResults will run in the context of the main thread, the code in ShowResults should be as minimal as possible—read: as fast as possible. Once you enter into the Synchronize (or Que
Post a Comment
Read more

Autorelease Pool

-
Manual memory management requires some thought and ceremony. It is not so much of a problem with long-lasting instances, but managing temporary local objects, especially when you need to create more than one, is a tedious job. It also hurts code readability. While Delphi allows automatic memory management for classes that implement interfaces, using ARC is not always feasible. If you have to deal with preexisting classes that don't support ARC, you will have to deal with manual memory management. Reference counting also adds some overhead, and using reference counting in your own classes is not always a viable approach. When performance is not paramount, simpler and cleaner code without try...finally blocks would be nice to have. Life always finds a way and various ARC-based smart pointer and similar lifetime management wrapper implementations have started to appear in the wild. One common place where constructing many object instances can be found is unit testing. While lifeti
3 comments
Read more

Delphi Event-based and Asynchronous Programming Book - Paperback Edition and Invitation to Webinar

-
Image
 You asked for it, and here it is!  The paperback version of the book is here! (I hope Gaia will forgive me again...) Celebrating the release of the new book, “Delphi Event-based and Asynchronous Programming,” Jim McKeeth and I will have a chat about it during a webinar featuring a Q&A where I'll be answering your questions. Let's not reinvent the wheel here... here's the intro Jim McKeeth wrote: Join Embarcadero MVP Dalija Prasnikar and Jim McKeeth for this fireside chat about Event-Based and Asynchronous Programming in Delphi. This is your chance to get answers to your questions on the topic. Register for the webinar here: https://register.gotowebinar.com/register/9060745883744641039 Learn even more from Dalija’s recently published 291-page book: “Delphi Event-based and Asynchronous Programming,” and score a 50% discount on the physical book if you purchase the ebook!  If you have already purchased the eBook version, and wish to buy the paperback, you're also elig
Post a Comment
Read more

If it is too complex, you are probably doing it wrong

-
If there is one thing experience has taught me, it is that too much complexity in some code usually means that design is wrong. That does not mean that everything must and can be as simple as 2 + 2, but complexity should sound some inner alarm and should make you reconsider your approach. If basic concept, without all convenience features is hard to follow then it is most certainly wrong. Adding convenience features can bring some additional layers of complexity and certainly plenty of code, but they don't usually pose a significant problem if basic concept is done right. There are many practices, patterns and advices going around that should help writing clean and maintainable code, but two stand before all else. Violate them and you will be in trouble, sooner or later (usually sooner or in the worst possible moment). KISS - Keep it simple stupid -  https://en.wikipedia.org/wiki/KISS_principle YAGNI - You aren't gonna need it -  https://en.wikipedia.org/wiki/You_aren't_gon
Post a Comment
Read more

Code examples from Delphi Event-based and Asynchronous Programming Book

-
Image
  A little birdie once told me that having code examples from my book in a friendlier form would be highly appreciated. Of course I heard the friendly chirp  So here it is! The full list of code examples from the book Delphi Event-based and Asynchronous Programming is available for you to download from my GitHub page: https://github.com/dalijap/code-delphi-async
Post a Comment
Read more

Are const parameters dangerous?

-
Image
Marco Cantu's recent blog post The Case of Delphi Const String Parameters opened a can of worms. A very, very old can... The presented behavior is not something new, and it is certainly not a compiler bug. It is just the way reference counting works. A pure ARC problem—one instance of something is destroyed when the other one is created and assigned, because the const parameter did not trigger the reference counting mechanism—this is why const is used for speed optimization in the first place. The same thing that happens with strings happens with reference-counted objects, but it is easier to see what happens with objects in the same kind of code. You will need a form with a memo and a button to test the following code: type IFoo = interface function GetCount: Integer; function GetNumber: Integer; end; TFoo = class(TInterfacedObject, IFoo) private FNumber: Integer; public constructor Create(ANumber: Integer); destructor Destroy; override; f
Post a Comment
Read more

Just released: Delphi Event-based and Asynchronous Programming - Complete version - 291 Pages

-
Image
 Delphi Event-based and Asynchronous Programming https://dalija.prasnikar.info/delphiebap/index.html Event-based programming is everywhere. Nowadays, you can hardly write any kind of application without leaning on events and messages. This simple, yet extremely powerful mechanism is also the cornerstone of asynchronous and multithreaded programming. Without events, we would not know when some task was completed. But, asynchronous and multithreaded programming consists of more than just handling multiple threads, protecting shared resources, and synchronization. It also includes designing and understanding program flow. That design aspect is often forgotten, taken for granted, and solving all the fine-grained nuances of multithreaded programming hogs the spotlight. Without understanding asynchronous flow and the bigger picture it can be hard to properly solve all the other issues, including multithreading. What used to be plain spaghetti code, now becomes temporal spaghetti. You can los
Post a Comment
Read more