Thursday, November 08, 2018

Using configuration records and operators to reduce number of overloaded methods

When writing libraries you sometimes want to provide users (that is, programmers) with a flexible API. If a specific part of your library can be used in different ways, you may want to provide multiple overloaded methods accepting different combinations of parameters.

For example, IOmniPipeline interface from OmniThreadLibrary implements three overloaded Stage functions.

function  Stage(pipelineStage: TPipelineSimpleStageDelegate; 
taskConfig: IOmniTaskConfig = nil): IOmniPipeline; overload;
function  Stage(pipelineStage: TPipelineStageDelegate; 
taskConfig: IOmniTaskConfig = nil): IOmniPipeline; overload;
function  Stage(pipelineStage: TPipelineStageDelegateEx; 
taskConfig: IOmniTaskConfig = nil): IOmniPipeline; overload;

Delphi’s own System.Threading is even worse. In class TParallel, for example, there are 32 overloads of the &For class function. Thirty two! Not only it is hard to select appropriate function; it is also hard to decode something useful from the code completion tip. Check the image below – can you tell which overloaded version I’m trying to call? Me neither!

overloads1

Because of all that, it is usually good to minimize number of overloaded methods. We can do some work by adding default parameters, but sometimes this doesn’t help. Today I’d like to present an alternative solution – configuration records and operator overloading. To simplify things, I’ll present a mostly made-up problem. You can download it from github.

Wednesday, June 20, 2018

Delphi - always full of surprises!

After all these years, Delphi still surprises me. Apparently, as I found out today (by making a stupid typo), Copy(string, index, count) doesn't require the count parameter!

IOW, following two lines do exactly the same:

s := Copy('123456789', 4, 6);
s := Copy('123456789', 4);

Works for arrays, too!

Of course, this is not documented.

See for yourself:

program ProjectCopy;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  SysUtils;

var
  s1: TArray;

begin
  Writeln(Copy('123456789', 4, 6));
  Writeln(Copy('123456789', 4));
  s1 := ['1', '2', '3'];
  Writeln(string.Join(',', Copy(s1, 1, 2)));
  Writeln(string.Join(',', Copy(s1, 1)));
  Readln;
end.

This code outputs (in Tokyo):

456789
456789
2,3
2,3

I'd suspect that this goes waaaaaay back. I tested string version with XE2 and it works the same as in Tokyo.

Sunday, May 20, 2018

Introducing MultiBuilder




When I'm working on OmniThreadLibrary, I have to keep backwards compatibility in mind. And man, is that hard! OmniThreadLibrary supports every Delphi from 2007 onward and that means lots of IFDEFs and some ugly hacks.

Typically I develop new stuff on Berlin or Tokyo and then occasionally start a batch script that tests if everything compiles and runs unit tests for all supported platforms in parallel. (I wrote about that system two years ago in article Setting Up a Parallel Build System.) Dealing with 14 DOS windows, each showing compilation log, is cumbersome, though, and that's why I do this step entirely too infrequently.

For quite some time I wanted to write a simple framework that would put my homebrew build batch into a more formal framework and which would display compilation results in a nicer way. Well, this weekend I had some time and I sat down and put together just that - a MultiBuilder. I can promise that it will be extensively used in development of OmniThreadLibrary v4. (Which, incidentally, will drop support for 2007 to XE. You've been notified.)

The rest of this post represents a short documentation for the project, taken from its GitHub page.

I don't plan to spend much time on this project. If you find it useful and if you would like to make it better, go ahead! Make the changes, create a pull request. I'll be very happy to consider all improvements.

Monday, May 14, 2018

See you in Piacenza!

It is now official - I'll be participating both as a seminar and as a conference speaker on Delphi Day 2018 in Piacenza. This is a new experience for me - I had quite some presentations in Italy so far and I know that Italians are both great participants and excellent hosts, but I was never part of Delphi Day.

On June, 6th I'll lead a seminar titled Writing High Performance Delphi Applications. It will be based on material from my Delphi High Performance book. We will look into variety of topics - algorithmic complexity, performance considerations when using built-in Delphi types, memory manager internals and optimisations and parallel programming. This will also be a good chance to grab a signed copy of the "high performance" and Parallel Programming with OmniThreadLibrary books (wink, wink ;) ).

Next day I'll participate on the conference programme with a talk called Defensive programming for a better future. Without even starting Delphi (look ma, no hands!) I'll look into different areas of programming where some common sense and simple guidelines can represent a difference between well- functioning code and a nest of bugs.

See you!


Wednesday, April 25, 2018

Multithreading is (still) hard!

Multithreading is hard!

No matter how long you deal with it and how good you (think) you are, you will make a mistake. Usually, it will be a problem that will only exhibit itself in a rare circumstances, most probably on a hard-to-reach customer machine. With some (bad) luck it will only appear on Friday afternoons or during your vacation.

That is why I'm always introducing multithreading with the "Don't do it yourself!" motto. Use a standard library! (And by that I mean OmniThreadLibrary, of course. ;) ) As your code, it too will have bugs. Unlike your code, it has 1000+ users running it in very different environments which means that at least it is tested as much as possible.

There are, nevertheless, bugs that escape detection for a long time. In 2011, for example, I fixed a well-hidden problem in TOmniBlockingCollection ("Multithreading is Hard!"). As nasty as that was, it was nothing compared to the bug I found recently!

As it turned out, the implementation of a bounded (fixed-size) multiple-producer multiple-consumer lock-free queue TOmniBoundedQueue (try saying that in one breath!) was buggy since its inception! As this queue is basis to all OmniThreadLibrary communication channels it is really surprising that the bug hid from everybody for 9 (yes, nine!) long years.

Friday, March 02, 2018

Delphi High Performance

My second book was also released these days. I wrote it for Packt Publishing, a publishing house which has recently started printing Delphi titles. The first was Delphi Cookbook by Daniele Teti, a very successful title that was followed by Delphi Cookbook - Second Edition by the same author.
Last year they published Expert Delphi by Paweł Głowacki, followed this year by my book and (as I have it on a good authority) at least one more. All books are available in electronic and printed formats. They also offer Delphi video lectures.

Delphi High Performance Book CoverDelphi High Performance is, as the name says, a book about writing Delphi applications that perform well. That does not mean writing multithreaded applications - and I say this many times in the book. To write high performance applications you need to known much more. The book therefore starts with the basics - with the algorithms, how we can classify them, how they behave and how can we pull the most from the built-in Delphi data structures. Then it moves to profilers because you should never guess what the slowest part of the code is. Always measure!

Writing a book that tells you "this is how you make your algorithm faster" is, sadly, impossible. That's why we consultants are for ;) In the book I only gave few advises (with lots of examples) about working with the GUI and about caching results from calculations.

Only then do I go deep into Delphi. Writing fast applications means knowing how built-in data types behave. I look into data life-cycle, what happens when a data of some type is modified and how it is passed in function calls. The life-cycle part cannot be explained without talking about memory which brings in a discussion of memory managers in general and FastMM in specifics.

Only then does the book introduce multithreading. Whole three chapters are dedicated to it and one of them is specifically written to show you why multithreading is hard, what you should never do when writing multithreaded code and why you shouldn't approach this topic with a preconception that it will automatically speed up your code. Only then do I introduce TThread and modern concepts such as tasks, futures, parallel for and so on. Most of the time I stay with the Delphi RTL and show how modern multithreading concepts can be neatly implemented on that basis. Only at the end I introduce OmniThreadLibrary's concept of a pipeline.

At the end the book admits that sometimes you have to look around and find a prepackaged solution elsewhere. As this solution will be typically compiled for C or C++, the book shows how to link in C object files, how to write a proxy DLL which allows you to use a C++ library and at least tries to introduce you to the world of pain related to all that. Reading this book will definitely not give you enough information on the topic of linking, but at least it will give you a good starting point so that you can research further.

I really hope that you'll like this book. It was a great joy to write, but also lots of very hard work. At the end, all the hard work was immediately forgotten when Stefan Glienke (who very kindly reviewed the whole book and pointed out some glaring errors - Stefan, thanks!) said:
"This is the best Delphi book (for me personally) I've read since 'Delphi in a Nutshell'. It is 'must buy' for our department and mandatory that everyone reads it."

Wednesday, February 28, 2018

Parallel Programming with OmniThreadLibrary - the book is here!

My first book Parallel Programming with OmniThreadLibrary is finally out!

The book covers OmniThreadLibrary version 3.07.5 which was also released today.

As this book was always meant to be documentation for the OmniThreadLibrary, my job doesn't end here. I will update and enhance the e-book whenever OmniThreadLibrary is updated and modified. All owners of the e-book will get these updates for the lifetime of the book.

The printed book will also be updated, but most probably only with major updates to OmniThreadLibrary. There will not be an update for release 3.07.6 (if there will be such release), but most probably there will be a new version of printed book when OmniThreadLibrary 3.08 is released and there most definitely will be one when version 4.0 comes out.

Here are your options at the moment.

1. If you would like to own the ebook, go to LeanPub. You can buy an ebook for $29.99 and package containing ebook + three webinars about the OmniThreadLibrary for $34.99. You can also buy an organizational license which allows you to give as many copies as you want to members of your organization.

2. To buy the hardcover printed book go to Lulu. For the next month the price is reduced from $49.99 to $45.99 as an introductory offer! I'm still deciding the possibility of also releasing a paperback version but I'm not entirely sure about that as paperback binding on Lulu is reportedly not of high quality. A price of the paperback would be about $10 lower than the price of the hardcover (that is the difference in print costs) and if you think that would make a difference for you, leave me a note.

3. To buy both versions (ebook and printed), go to Lulu and buy the printed book first! You will get an email with a link for ebook at reduced price $9.99 (and combo with webinars for $14.99).

All existing owners of the electronic book should have already received an email with notification about the new release. This email also contains a link to a specially reduced printed book for mere $29.99! If you previously bought the ebook but didn't receive the email, let me know!

Before I sign out for today, let me tell you that writing this book was lots of hard work but also a great joy and I could never do it without all the great people who bought the ebook before it was even completed. Thank you!



OmniThreadLibrary 3.07.5

OmniThreadLibrary 3.07.5 has been released. You can get it at GitHub or download the ZIP.

There are only small number of changes in this release.

General improvements

  • Reduced number of times NameThreadForDebugging is called when threadpool is used.

Bug fixes

  • [VyPu] fixed race condition in TOmniCriticalSection.Release which affected code that was using TOmniCriticalSection.LockCount.
  • OtlThreadPool did not respect OTL_DontSetThreadName define.


Tuesday, February 13, 2018

Data-driven Multithreading

About a week ago, Craig Chapman posted a vlog Lockless Multi-Threading in Delphi where he programmed a lockless communication channel which transfers messages between the main thread and a worker thread (or, actually, between any two threads).

I do like Craig's implementation of a lockless queue. It is small, neat, and working. I also like that he approached multithreading from a communication viewpoint. I do, however, have several issues with how it is integrated into the application. While I whole understand the need for simple demo that viewers can understand, I feel that the Delphi world is full of such examples. That makes it hard for a newcomer to the multithreaded world to find appropriate patterns to copy.

Hence I decided to rewrite Craig's code with different objectives in mind. Instead of speed I focused on flexibility, ease of use and good multithreaded programming patterns. Before I jump into my solution, however, I must articulate the bad programming practices in the Lockless demo. (That is strictly subjective reasoning. Your mileage may vary. It is, alas, a reasoning supported by many many years of writing bad multithreaded code - and not yet enough years of writing good code.)

Saturday, February 03, 2018

Books, wonderful books!

I love reading. I loved it since the (very) young days. As far as I remember, books were my friends.

I also love - as I somewhat surprisingly discovered in my twenties - teaching and writing. I always kept to the short form - blog posts, magazine articles, and so on. Always - until few years ago I somehow decided that documenting OmniThreadLibrary would be best done in a form of a book.