Re: Threads - Mailing list pgsql-hackers

On Fri, 2003-01-03 at 14:52, Dann Corbit wrote:
> > -----Original Message-----
> > (1) One thread screws up, the whole process dies. In a 
> > multiple process 
> > application this is not too much of an issue.
> 
> If you use C++ you can try/catch and nothing bad happens to anything but
> the naughty thread.

That doesn't protect against the type of issues he's talking about. 
Invalid pointer reference is a very common snafu which really hoses
threaded applications.  Not to mention resource leaks AND LOCKED
resources which are inherently an issue on Win32.

Besides, it's doubtful that PostgreSQL is going to be rewritten in C++
so bringing up try/catch is pretty much an invalid argument.

>  
> > (2) Heap fragmentation. In a long uptime application, such as a 
> > database, heap fragmentation is an important consideration. With 
> > multiple processes, each process manages its own heap and what ever 
> > fragmentation that exists goes away when the connection is closed.  A 
> > threaded server is far more vulnerable because the heap has to manage 
> > many threads and the heap has to stay active and unfragmented in 
> > perpetuity. This is why Windows applications usually end up 
> > using 2G of 
> > memory after 3 months of use. (Well, this AND memory leaks)
> 
> Poorly written applications leak memory.  Fragmentation is a legitimate
> concern.

And well written applications which attempt to safely handle segfaults,
etc., often leak memory and lock resources like crazy.  On Win32,
depending on the nature of the resources, once this happens, even
process termination will not free/unlock the resources.

> > (4) Lock Contention. The various single points of access in a process 
> > have to be serialized for multiple threads. heap allocation, 
> > deallocation, etc all have to be managed. In a multple process model, 
> > these resources would be separated by process contexts.
> 
> Semaphores are more complicated than critical sections.  If anything, a
> shared memory approach is more problematic and fragile, especially when
> porting to multiple operating systems.

And critical sections lead to low performance on SMP systems for Win32
platforms.  No task can switch on ANY CPU for the duration of the
critical section.  It's highly recommend by MS as the majority of Win32
applications expect uniprocessor systems and they are VERY fast.  As
soon as multiple processors come into the mix, critical sections become
a HORRIBLE idea if any soft of scalability is desired.


> Is it a FAQ?  If not, it ought to be.

I agree.  I think mlw's list of reasons should be added to a faq.  It
terse yet says it all!


-- 
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting