Saturday, December 24, 2016

Colours on my keyboard

A few days ago I had to consider reinstalling Windows on my notebook. Instead I decided to switch to Linux Mint. I've been using Linux Mint in virtual machines for a few years and it worked very well for me. This is the first time I run Linux directly on the host. For development I keep a few Windows virtual machines. I'm very happy with it so far. Everything just worked without much ado, except one detail: The notebook comes with a backlit keyboard with configurable colours. Under Windows I got used to setting it to a dim white colour which works best for me. Since the default colour on boot is dark blue I was looking for a way to change it in Linux. Luckily, I've found a driver for it.

Big kudos to Steven Seeger (klystron) for his efforts!

I can enjoy my comfortable dim white colour again. Or play around; see below. ;-)

Happy holidays and a great year 2017 to everyone!




Saturday, October 15, 2016

Delphi Perspectives: Kick-Start or the Last Kicks?

I've received another e-mail offer from Embarcadero to upgrade my Delphi 10.1 Berlin Starter Edition to Professional for €749 (claiming to save over €2000). The offer is valid this weekend only and includes:
  1. Delphi 10.1 Berlin Professional upgrade
  2. Mobile Add-On Pack
  3. "Bonus Packet" with VCL and FireMonkey Styles, Konopka VCL Controls and Marco Cantù's Object Pascal Handbook
After Embarcadero shut down their R&D centers (with no public statement) and let go of people like Allen Bauer and David Intersimone I start wondering: Is this the beginning of the final sell-out? On a more positive note, the new General Manager mentioned in an interview (PDF) that they wanted to attract new developers and get back into education. Hints of this happening are already here.

Let's see what happens...

Sunday, September 11, 2016

Potential Deadlocks in Parallel.For

Recently, I've come across some C# code deadlocking quite reproducibly while executing some tasks using Parallel.For method. The seemingly innocuous code lead to an "obscure situation" exactly as described in this blog post by Stephen Toub:
Does Parallel.For use one Task per iteration?
...iterations are handed out in indivisible chunks, and only one thread is involved in the processing of a particular chunk. This has implications for interdependencies between iterations. If iteration i blocks waiting for iteration i + 1 to be completed, and iterations i and i + 1 are both allocated to the same chunk, the loop will likely deadlock. The thread processing those iterations will block processing iteration i, but as that thread is also responsible for processing iteration i + 1, iteration i + 1 will never get processed and iteration i will never unblock.
The problem in this case was exactly as described above: there were blocking wait dependencies between the tasks in a producer/consumer pattern. The solution (once the problem was clear) was relatively simple: don't rely on the default partitioning of Parallel.For; provide your own to avoid the potential deadlock.

A good framework or library can provide you with a good-enough solution in a large-enough percentage of possible use cases (probably making some compromises to achieve that goal). Don't expect a pre-fabricated solution to solve all your problems out of the box; There is no silver bullet.

Here's some interesting reading about the Parallel.For implementation in .NET and trade-offs between simplicity, overheads, and load balancing:
Patterns of Parallel Programming (Understanding and Applying Parallel Patterns with the .NET Framework and Visual C#)