Concurrency without threads

Question

I have this single monolithic daemon which does multiple operations like interfacing with north bound APIs, interfacing with south bound APIs, executing state machines, building internal databases.

Currently I ended up with scalability issues and I want to redesign the daemon so that all the multiple actions inside the daemon are made concurrent. But using threads will complicate the logic since I end up having to:

• Add locks for synchronization.
• Take proper care for future extensions.
• Debug the timing issues.

So my question is please suggest a design approach where I can still make the actions concurrent and remove the complexity of threads.

My application is currently in C. Any sample open source (FOSS) project as example would also help me to understand the design approach.

Answer 1

Your only remaining options are:

• Multi-process approach (ie: spawn(), fork(), exec(), etc. You still need to synchronize data, setup shared memory, etc. Threads would likely be easier).
• Bite the bullet and live with no concurrency.
• Become proficient in "lock free / lockless programming" approaches, which will still likely require atomic operations at the least.

Software sync, protection, and future-proofing/scalability are common problems in any production code that does non-trivial operations. Trying to avoid them outright usually indicates you have bigger concerns than avoiding threaded models.