On 26 Sep 2001, Ian Lance Taylor wrote: > > > Save for the fact that the kernel can switch between threads faster then > > it can switch processes considering threads share the same address space, > > stack, code, etc. If need be sharing the data between threads is much > > easier then sharing between processes. > > When using a kernel threading model, it's not obvious to me that the > kernel will switch between threads much faster than it will switch > between processes. As far as I can see, the only potential savings is > not reloading the pointers to the page tables. That is not nothing, > but it is also not a lot.
It is my understanding that avoiding a full context switch of the processor can be of a significant advantage. This is especially important on processor architectures that can be kinda slow at doing it (x86). I will admit that most modern kernels have features that assist software packages utilizing the forking model (copy on write for instance). It is also my impression that these do a good job. I am the kind of guy that looks towards the future (as in a year, year and half or so) and say that processors will hopefully get faster at context switching and more and more kernels will implement these algorithms to speed up the forking model. At the same time, I see more and more processors being shoved into a single box and it appears that the threads model works better on these type of systems. > > I can't comment on the "isolate data" line. I am still trying to figure > > that one out. > > Sometimes you need data which is specific to a particular thread. When you need data that is specific to a thread you use a TSD (Thread Specific Data). > Basically, you have to look at every global variable in the Postgres > backend, and determine whether to share it among all threads or to > make it thread-specific. Yes, if one was to implement threads into PostgreSQL I would think that some re-writing would be in order of several areas. Like I said before, give a person a chance to restructure things so future TODO items wouldn't be so hard to implement. Personally, I like to stay away from global variables as much as possible. They just get you into trouble. > > That last line is a troll if I every saw it ;-) I will agree that threads > > isn't for everything and that it has costs just like everything else. Let > > me stress that last part - like everything else. Certain costs exist in > > the present model, nothing is - how should we say ... perfect. > > When writing in C, threading inevitably loses robustness. Erratic > behaviour by one thread, perhaps in a user defined function, can > subtly corrupt the entire system, rather than just that thread. Part > of defensive programming is building barriers between different parts > of a system. Process boundaries are a powerful barrier. I agree with everything you wrote above except for the first line. My only comment is that process boundaries are only *truely* a powerful barrier if the processes are different pieces of code and are not dependent on each other in crippling ways. Forking the same code with the bug in it - and only 1 in 5 die - is still 4 copies of buggy code running on your system ;-) > (Actually, though, Postgres is already vulnerable to erratic behaviour > because any backend process can corrupt the shared buffer pool.) I appreciate your total honest view of the situation. -- //========================================================\\ || D. Hageman <[EMAIL PROTECTED]> || \\========================================================// ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org