On Wed, 2005-07-27 at 13:31 -0400, Andrew Piskorski wrote: > On Tue, Jul 26, 2005 at 10:21:22PM -0400, Mrs. Brisby wrote: > > > That's incorrect. Threading increases development time and produces less > > stable applications. In fairness: it's the skill level of the engineer ... > When people - even smart and knowledgeable people - say "thread", they > typically mean one of two related but quite distinct concepts, and > they often don't say precisely which they mean: [snip]
I don't think there's any confusion here: We certainly are referring to shared memory concurrent multiprogramming. If someone was accidentally referring to something else, then they can be safely excused. This discussion was never academic, but practical. There aren't any transactional memory systems being used here. Javascript, LISP, Perl, TCL and Erlang aren't relevant, because people using SQLite on those platforms with those languages aren't having the multi-threading problems that spawned this discussion. People using those languages to do real work aren't running into the problems that we're talking about. You brought up some excellent examples of "highly successful" programs that use threads or thread-think. I commend that. It's also completely irrelevant. It's not that nobody can use threads safely- it's that those who can rarely chose to use threads because the skillset that comes with knowing how to use threads safely is axillary to the skillset that comes from knowing how to use "goto" safely, and how to write serialized event-driven applications easily. I keep using terms like "thread-think" and "process-think" and "event-think": It's evident that one can write event-driven programs with threads (Amoeba), or processes-think programs with threads (perl) or process-think programs with events (GNU Pth) or event-think programs with processes (yay signals). thread-think is the idea of having two basic constructs, "UP" and "DOWN"- without these two constructs (and having their accepted meaning) no memory access nor IPC is atomic. process-think considers all memory access atomic, but not necessarily IPC. meanwhile, event-think considers memory access AND IPC access atomic. This is as close to "transactional memory" as exists and is useful. It's also the mindset that I suggest to new programmers, and the one I myself find myself using often. Sometimes it _does_ matter. Sometimes, with the aid of a profiler, someone can find out exactly how to squeeze a little bit more performance out of this application. But: nobody on this list having problems with threads is using threads for that reason. Or rather, if they are, they're not complaining.
