Design decisions

When architecting a system, it is inevitable to make certain high-level design decisions.

Some of these decisions, if they’re wrong, can lead to the re-architecturing and re-writing of the whole system some months later, so there is an incentive to keep things rather generic. On the other hand, trying to make system too generic is just another recipe to disaster (usually expressed in terms of missed deadlines and unmanageable code).

IT Hares try to describe certain not-so-obvious architectural decisions, and some considerations which should be kept in mind while making them.

Multi-threading at Business-logic Level is Considered Harmful

September 7, 2015 by • “No Bugs” Bunny

Quote:

However, the window for triviality is very narrow: for example, even going into two interrelated mutexes instead of one, can easily make multi-threading non-trivial

Another Quote:

Technically you are able to jump to any point of your program, but the variables you see may (and if you have a multi-threaded bug – will) differ every time you jump there.

Filed under: On.System Architecture Design decisions On.Programming Debugging

Tagged With: Multithreading Overload