I’m aware of lock-free data structures, but they are usually only applicable to very specific problems which are not really present in the SmartInspect libraries. For instance, consider the core of the SmartInspect class which is, among other things, responsible for managing/creating the connections, connecting, disconnecting and writing the log packets. We need to take care that even if multiple threads try to simultaneously change the connections string, the enabled status or write one or more log packets, the SmartInspect class handles this correctly. Without using locks, this would be, I guess, nearly impossible to get right.
We haven’t decided on the SmartInspect 3.0 release date yet, but it won’t make it this month. I am preparing a blog series on some upcoming SmartInspect features in which I can probably give a few more details about a release date.
I’m sorry to hear that this problem is preventing you from using SmartInspect but fixing/minimizing this particular issue unfortunately takes some time. Implementing support for asynchronous I/O handling/logging is quite complex in a feature-rich framework such as SmartInspect. Also, I would like to point out once more that all logging frameworks somewhat change the threading behavior and the particular situation you have described cannot be prevented altogether but merely reduced/minimized. To minimize this problem, SmartInspect 3.0 will introduce a new asynchronous protocol option which allows to move the (potentially blocking) I/O operations to a different (possibly lower-priority) thread.