On Feb 17, 2008 11:16 PM, Geoff Steckel <[EMAIL PROTECTED]> wrote: > David Higgs wrote: > > Assuming that a software program is not system-critical or requires > > high security, and it benefits greatly from a shared memory/resource > > model, I fail to see why threading can not be cost-effective. > > May I interpret this as saying "Threads are cost-effective in programs > which don't have to be reliable"? If so, what you're saying is > irrelevant to the argument I'm making. > > As an aside, I prefer all programs I use to be as reliable as possible.
As do I, but my point is that not all programs have the same reliability requirements. > The only programs which I can see which could possibly justify > threads are strict SIMD. Any other cases where threads are proposed as > an optimal solution strongly suggest a very sloppy partitioning of data > or functionality. I think others may have a different opinion due to their own requirements and experiences. The benefits you extol upon multi-process programs do not come without a cost, otherwise there would have been no reason to invent threads in the first place. Furthermore, I would think that designing message-passing and notification mechanisms for a threaded program is of similar complexity to the marshalling, serialization, and validation mechanisms for inter-process communication. > > Using 'goto' and 'snprintf' in C software are also considered > > potentially harmful and easy to misuse. But OpenBSD does not limit > > their use; they CAN be used correctly and without error. The same > > applies to threads: only when appropriate. Since you (presumably) use > > OpenBSD, I hope you trust developers to decide when threading is and > > is not appropriate. > > In C, goto cannot be used non-locally. > C is vulnerable to buffer overruns. That requires vigilance. However, > the scrutiny needed to ensure snprintf and the like are not a problem is > also local. > Threading is a non-local vulnerability. Errors caused by misuse of goto can cause global effects. Buffer overflows can have non-local effects as well, and can cascade through flawed single-threaded programs just as easily as multi-process or multi-thread programs. It is harder to verify threaded programs for correctness, and the consequences of program flaws can be magnified when using threads over processes. However, it does not follow that threading is a vulnerability in and of itself. With suitable vigilance, I see no reason why a threaded program cannot be as secure or reliable as a multi-process program. It feels like I'm arguing semantics here (again?). I acknowledge that use of threading in most system utilities would be ill-advised, and that if applied incorrectly can lead to an insecure and unreliable system. I would simply like you to see my point, which is that regardless of your personal tastes, threading is not innately evil. --david
