De grijpbare thread

Vaak hoor ik dat ontwerpers met het oog op complexiteit een maximum stellen aan het aantal threads dat ze gebruiken. Ook bij designs met een zorgvuldig en correct vastgesteld aantal threads blijkt de resulterende hoeveelheid veelal een onoverkomelijk obstakel. Enkel dit aantal is dan een reden om te stellen dat het ontwerp niet deugt. Toch is dit het spreekwoordelijk vergelijken van appels en peren.

Het aantal threads mag nooit een doel op zich zijn, zolang dat aantal maar niet conflicteert met de beschikbare resources. Evenmin mogen we het gebruiken om een ontwerp op af te rekenen. Waarom nemen veel designers in de praktijk dan toch hun toevlucht tot een beoordeling van het aantal? Simpelweg omdat dat grijpbaar is, terwijl het concept concurrency complex is en moeilijk te doorgronden, en daarmee minder grijpbaar. Een dergelijke beoordeling zegt echter meer over de kennis van de persoon dan over het ontwerp van het systeem.

Concurrency is complex, dat weten we allemaal, maar de meeste problemen op dit gebied ontstaan doordat we niet vanaf het begin van het ontwerp een gedegen analyse maken van de concurrencybehoefte binnen het systeem. Het vaststellen van deze behoefte is een taak van de architect. Het is niets meer of minder dan het mappen van een logisch ontwerp op de beperkte verwerkingscapaciteit die ter beschikking staat. Als een computer oneindig snel zou zijn, hadden we geen behoefte aan concurrency, dan was die impliciet aanwezig. Helaas is het nog niet zover.