Concurrency is an ability of the program to execute its control sequence out-of-order or in partial order. This will inevitably cause Race Condition# due to the possible simultaneous access to the same resource. The security might not be sufficient to guard the shared memory from being exploited by an intruder.
That being said, designing a program with concurrency in mind will lead to a smoother workflow, cleaner architecture, clearer interface, and better performance, and allow more rooms for scaling and performance optimisation. The Pragmatic Programmer We can get rid of time or order dependencies by inspecting whether there are tasks or actions that could be happened in parallel with the help of tools such as UML activity diagram. Thinking it in a linear order instead will definitely result in a temporal coupling, that is, coupling in time, where tick must happen before tock.
Hungry consumer model, advocated by Hunt et al., emphasises the use of services: independent, concurrent objects encapsulated behind well-defined consistent interfaces, instead of favouring a central scheduler among consumers#. In this way, they will consume tasks from a work queue without bothering others’ business, and if they finished, they will grab some more from the queue. Let’s say that a consumer task get bogged down because of large input data, others will just pick up the slack. It allows every consumer to proceed data in their own pace.
However, such a design mindset will require all objects in the program to be in a valid state at all time, at least when being called. Make sure that the constructor leaves the object in an initialised state by adhering to some principle such as C++ Rule of Thumb.
Always look for a parallelism solution such as in #this example.