Let's Code Jumi #271: Concurrency Bug (Part 4)

Download as MP4

Episode Archive


  1. Fullscreen for video seems to have broken on this page (when watching form Episode Archive it does work just fine).

    I also spotted that concurrency issue with tracking current working count and calling it done whenever the count drops to zero. But I am also a bit curious about this choice to delay all execution of the messages until you have collected them all. For me it seems to contradict the concurrency requirements. Given the 'Im done' signal, isn't it possible to let the messages execute directly and more or less just pass on the 'im done' signal when it have arrived and all messages have been handled? (It's the queuing up part I do not understand.) Then again I might have misunderstood the purpose of 'initialWorkers'.

  2. IIRC, the idea was that there is only a few initial workers, perhaps only one, and those initial workers will (transitively) start all workers. In episode 273 the "initial workers" have been replaced with a new design that also has better concurrency.

    Tough I'm not sure whether I like the WorkerCounter even then. It's a bit smelly because it uses shared mutable state, but the rest of the system uses message passing. It's something that I'll keep an eye on. If it causes problems with new requirements, then I'll revisit this design and perhaps replace with pure message passing.