I recently had a debate with one colleague about the distinction between architectural design and detail design. Given an element in our software, how do we determine whether that element is an architectural element, or not?
In my previous Overload article I showed how one can achieve great speedups using tasks as the foundation for concurrent programming instead of locks. The one thing that is not clear is whether one can use tasks for all the concurrent algorithms. Tasks may be applicable to certain types of problem, but not to all problems. This article tries to complete the picture by showing that all algorithms can use tasks and there is no need for locks.
At this point, I’m decided to pass most of my articles to Overload. I still have the freedom to talk about the topics that are close to my heart, but I also get all the benefits of publishing in a peer-reviewed journal. I highly appreciate the high-quality feedback coming from the reviewers, and the professionalism of all involved. Respect!
This article is proof that one can achieve high speedups by using task-based concurrency rather than locks. I personally was delighted with the results after working our the formulas.
Another article I wrote appears in Overload: Deconstructing Inheritance.
The article tries to perform a critique of Inheritance as it is present in mainstream OOP. We look from multiple points of views on the Inheritance relationship, and we show that, at a closer inspection, it doesn’t reach up to the promises it makes. The article touches the simple problem of the Rectangle and Square, it discusses the parallel with the is-a relationship, and it shows how the Liskov Substitution Principle runs against inheritance.
You have an application. You add threads to improve throughput. But how many threads do you add? Do you go for a fixed number, or you compute this dynamically?
We try to articulate an answer in this post.