The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,980 other followers

Archive for May 27th, 2020

Davidlohr Bueso on Twitter: A programmer had a problem. He thought to himself, “I know, I’ll solve it with threads!”. has Now problems. two he

Posted by jpluimers on 2020/05/27

When doing multi-threading, I’m always reminded of [WayBack/Archive.isDavidlohr Bueso on Twitter: A programmer had a problem. He thought to himself, “I know, I’ll solve it with threads!”. has Now problems. two he

Even with the advent of multi-core architectures long behind us (multi core hardware has been in a mature state for a long time), software for it often is not.

It is not just that programmers are not ready to do it (indeed often they are not: multi-threading is hard), but also that many pieces of software run perfectly fine in a single thread.

So when you do want to implement multi-threading, think twice.

It is one of the reasons I ported a C# version of the Deadlock Empire game (written in HTML + JavaScript) to generate Delphi code and examples. I was really glad that Dalija Prasnikar pointed to it in [WayBack] What is thread safety anyway?, and also pointed to the very important [WayBack] What is this thing you call “thread safe”? – Fabulous Adventures In Coding.

That last one stresses that multi-threading has vague definitions. It will stay vague because the problems you can encounter are virtually endless. There is no silver bullet: Lars Fosdal made this really nice remark in [WayBack] Multithreading can be hard to do right… – Dalija Prasnikar – Google+:

Locking too much is even worse than locking too little. It is very easy to deadlock with overly detailed locking. Applying locking in the wrong place, can serialize threads through a lock bottleneck.

Learning multithreading is a long series of mistakes that you probably can’t avoid, even if told about them up front. You are probably best off having to make the mistakes yourself and then learn from them ;)

To which Asbjørn Heid added:

… after a while I came to the realization that recursive locks are evil. They make it so easy to “just lock everything”. In contrast, non-recursive locks forces you to have explicit “thread-safety borders” in your code. And such borders really leads to better designs.

Here are the games:

Related:

–jeroen

 

 

Posted in Conference Topics, Conferences, Development, Event, Multi-Threading / Concurrency, Software Development | Leave a Comment »

Need to look at monospaced programmers fonts again

Posted by jpluimers on 2020/05/27

At the time of looking, FiraCode would not work in Delphi but would in Visual Studio. Reminder for me to look at it again: [WayBack] GitHub – tonsky/FiraCode: Monospaced font with programming ligatures.

A cool feature of the font is that it has ligatures for common multi-character combinations like := or ...

Back when scheduling this, I was still at Lucida Console because of its large x-height and small line spacing.

It is time to revisit my font choice, so lets include at least these candidates:

–jeroen

related:

Edit 20200527: observations by Uwe Schuster

Posted in .NET, Delphi, Development, Font, Power User, Programmers Font, Software Development, Visual Studio 2015, Visual Studio and tools, Visual Studio Code | Leave a Comment »

 
%d bloggers like this: