To start off, I am fairly new to threading. One of the recent “module” requirements and other future “module” requirements caused enough reason to start a small framework for time-slotted batch services. Basically, the idea is to have a thread running one 'process' in a certain reoccuring time slot (let's say for every one hour). If a 'process' is unable to complete itself in the allocated time slot, the process then creates a splitted-process to participiate over multiple threads. In practical terms, the 'process' just continously splits itself into more processes until n amount of threads are able to allow a 'process' to complete its task within the allocated time slot. Something that I would like to call “splitting the atom.”

We all know that when we split atoms, it is followed by a “kaaaboooommmm!” That is why I was so wary when designing this framework. It works very well under simulated unit tests (I've written about a day's worth of code for testing). Extremely well. I can bet my next pay check that this thing is able to scale without a problem... and that is the source of my cold-sweeted nightmares. Generally, things can go terribly wrong with multi-threading and the usual cause is because there are race conditions happening. :-/. That is not the case under my framework -- there is no race conditions but I can't get rid of the images that I might get that “kaaaboooom” and dreaming about the possible framework enhancements to unleash some restrictions that might be encountered.

Do you get multi-threading nightmares at night?