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 2,161 other followers

Archive for the ‘Multi-Threading / Concurrency’ Category

.NET Rocks: How do you do concurrency?

Posted by jpluimers on 2020/06/23

Since it was quite a while ago I wrote heavily concurrent code in .NET, I wanted to know about the starte of the art.

This pod cast and the book discussed in it helped a lot: [WayBackHow do you do concurrency? Carl and Richard talk to Riccardo Terrell about his book on Concurrency in .NET.… – .NET Rocks! – Google+

Links referenced:


Posted in .NET, Development, Multi-Threading / Concurrency, Software Development | Leave a Comment »

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:





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

Terminate threads during application or not?

Posted by jpluimers on 2019/10/02

I got an interesting question a while ago: should an application terminate (anonymous) threads or not?

A problem is that a thread might not execute unless you call WaitFor before Terminate is called. The reason is that the internal function ThreadProc does not start Execute if the thread is already terminated.

The ThreadProc in the System.Classes unit is an ideal place to set breakpoints in order to see which threads might start.

Other useful places to set breakpoints:

  • TAnonymousThread.Execute
  • TExternalThread.Execute

Execute not being called by ThreadProc is a bug, but it is not documented because QC is gone (taking the below entry with it), it is not in QP and the docwiki never got updated.

Given QC has so much information, I am still baffled that Embarcadero took it down.

Sergey Kasandrov (a.k.a. serg or sergworks) wrote in [WayBack] Sleep sort and TThread corner case | The Programming Works about this bug and refers to WayBack: QualityCentral 35451 – TThread implementation doesn’t guarantee that thread’s Execute method will be called at all .

The really bad thing are the WayBack: QualityCentral Resolution Entries for Report #35451 Resolution “As Designed” implying the design is wrong.

In his post, sergworks implemented the Sleep sorting in Delphi. Related:

Note that application shutdown is a much debated topic. Best is to do as little cleanup as possible: your process is going to terminate soon anyway. No need to close handles or free memory: Windows will do that for you anyway. See for instance:


Related to waiting:

Related to executing:


Posted in Conference Topics, Conferences, Delphi, Development, Event, Multi-Threading / Concurrency, Software Development, The Old New Thing, Windows Development | Leave a Comment »

Sometimes a race condition is in just two lines of code

Posted by jpluimers on 2019/07/30

A race condition can be this small:

if Assigned(Setting.OnChanged) then

If in between these lines, the value of Setting.OnChanged becomes nil, then you have an access violation.

It is a very slim, but real chance.


Posted in Delphi, Development, Multi-Threading / Concurrency, Software Development | 4 Comments »

Laptop fan profiling, and debugging them – related to Profiling | CommitStrip

Posted by jpluimers on 2019/07/23

A while back, I posted the “profiling” CommitStrip on[WayBack] Profiling – Jeroen Wiert Pluimers – Google+. Boy how did I not know that within a week, I bumped into a “laptop fan profiling” artefact.

A coworker noticed, that when starting a thread based equivalent of [WayBack] TTimer Class (which cannot be used in services as it depends on the VCL), then sometimes the laptop fans would spin up.

What basically happened was that for certain combinations of Enabled and Interval the Execute would loop burning 100% of one CPU core.

With 3 or more – sometimes 2 – of these threads active on a 4+4 core (4 are hyper-threaded), the processor fan would start to spin like madness.

Finding the solution was somewhat easy too:

  • Process Explorer would show the thread IDs burning the most CPU cycles
  • Delphi shows the Thread IDs in the Thread Status pane (if they are named, the ID is at the end of the name in parenthesis)
  • At around Delphi 2010, you can Freeze or Thaw threads. This allows you to debug only a single thread by freezing all others.

Focussing on one thread, allowed a close inspection of the loop, quickly finding the actual cause and repairing it.

TTimer Thread

A similar and better class is at [WayBack] multithreading – TTimerThread – Threaded timer class – Code Review Stack Exchange, based on [WayBack] timer – Using VCL TTimer in Delphi console application – Stack Overflow.

Read the rest of this entry »

Posted in Conference Topics, Conferences, Debugging, Delphi, Development, Event, Fun, Multi-Threading / Concurrency, Profiling-Performance-Measurement, Software Development | Leave a Comment »

%d bloggers like this: