Long time, no post. Partially I was busy with other projects, but for a brief time, I was busy writing an article for ACCU. And, as you might have guessed, the article was called “Do Repeat Yourself”.
My previous posts on tasks and concurrency (Threads are not the answer, Look ma, no locks and Modern dining philosophers) ) all talk about tasks. But after all these posts, I’ve got the same question back what is the difference between a task and a thread?, in various forms.
This blog post is aiming at making some light on this difference.
I’ve recently re-read Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin et al. And, once again, I have mixed feelings about the book.
This post is discussing some weak points of the book.
People often talk about modularity in software design, about conquering complexity, about reducing coupling and about decomposition. But often those discussions revolve around some concrete examples. Although this is generally a good thing, there is always the question of “does it also apply to my case?” We should also be looking at this from a more abstract way, to approach the essence of things.
While this blog post is far from an exposition of the essence of these things, it attempts to start an investigation in this direction. Even in its abstract form, it can be useful to draw some practical conclusions. But more importantly, it is a starting point for having more detailed discussions on taming complexity.
How would one solve the dining philosophers problem at the end of 2018? It’s been 53 years since Dijkstra originally formulated the problem. Are we still using locks to solve it? Do we properly avoid deadlocks and starvation?
The vast majority of implementations I found doing an Internet search revealed to me that we are using mutexes or semaphores for it. But we mentioned previously that this is a bad approach; we should use tasks instead.
In this blog post, we give several solutions to the dining philosophers problem, each with some pros and cons. But, more importantly, we walk the reader through the most important aspects of using tasks to solve concurrency problems.