Re: Spinlock performance improvement proposal
От | Ian Lance Taylor |
---|---|
Тема | Re: Spinlock performance improvement proposal |
Дата | |
Msg-id | si8zf1vcau.fsf@daffy.airs.com обсуждение исходный текст |
Ответ на | Re: Spinlock performance improvement proposal ("D. Hageman" <dhageman@dracken.com>) |
Ответы |
Re: Spinlock performance improvement proposal
("D. Hageman" <dhageman@dracken.com>)
Re: Spinlock performance improvement proposal (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
"D. Hageman" <dhageman@dracken.com> writes: > > you have a newer kernel scheduled implementation, then you will have the same > > scheduling as separate processes. The only thing you will need to do is > > switch your brain from figuring out how to share data, to trying to figure > > out how to isolate data. A multithreaded implementation lacks many of the > > benefits and robustness of a multiprocess implementation. > > 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. > 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. 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. In other words, you have to take extra steps to isolate the data within the thread. This is the reverse of the current situation, in which you have to take extra steps to share data among all backend processes. > 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. (Actually, though, Postgres is already vulnerable to erratic behaviour because any backend process can corrupt the shared buffer pool.) Ian
В списке pgsql-hackers по дате отправления: