Re: Processes vs Threads

In article <3962g6$8c0_at_news.INbe.net> nick_at_falstaff "Nick Price" writes:

> The Oracle architecture is highly process centric, in that a typical
> instance architecture utiises (at least on UNIX) seperate processes to
> accomplish discrete tasks.
>
> The lightweight process/thread execution model (ie Pthreads) where
> therads execute within the address space of the parent process would seem
> to offer scope for considerable parallelism. How if at all could this
> model be used for a DBMS system such as Oracle ?
>
> Nick
> --
> +=================================================
> + Nick Price
> + Internet: nprice_at_innet.be
> + Tel/Fax : +32 2 347 1101
> +=================================================

Sybase use threads. And I'm sure that they'll find them a handicap if they don't already.

Threads! I hate them. They're so inelegant that they're bound not to be last. I've investigated them and I'm confident I can ignore them. My thoughts:

Unless you have kernel support for threads a la Sun then each threaded process has its own (hidden) scheduler thread. So the OS scheduler schedules the threaded process which splits its activity between the threads using its thread scheduler. So the ``fine control'' over scheduling often claimed as a benefit of threads is a fantasy: The thread scheduler has no control over how often the threaded process is itself scheduled by the OS. The task of the thread scheduler can be compared to that of a person balancing a pole on his head while another randomly turns the light on and off.

On the other hand if you don't have kernel support for threads then thread context switches can occur without intervention of the kernel (because each threaded process has its own scheduler) thus making context switching cheap. Perhaps that is the benefit of threads? No: any system call still requires the process to be suspended while the kernel copes with the request.

Whatever the benefit of threads (and it is my contention that there is none) they are an abomination to program. Just look at the calls in the pthread library! I'm glad Oracle use separate processes rather than threads. But I would like one simple extension to C or (are you listening, Oracle?) to Pro*C that would let a variable be declared as ``share'' so that both processes would have access to the same memory location after a fork(). I know it can be implemented using shared memory and I've written a little library to do it for me 'cos I seem to do it so often but I wish the language did it for me. Then the last excuse for the existence of threads - sharing the same address space - disappears and threads could certainly go hang themselves.

Once upon a time a Unix fork() was expensive. And lite processes seemed a good idea. But not anymore. fork() takes no longer than pThreadCreate() (or whatever it is called - I can no longer remember.)

Of course, MS Windows and VMS programmers love threads - they don't have (a proper or a cheap) fork(). Why do threads exist in the Unix environment if they are as useless as I say? Because then the likes of Transarc can provide portability between Unix, VMS and Windows via compatible threading libraries. Finally we have the reason for the existence of of threads. And that's why I'll ignore them: For the same reason I ignore VMS and MS Windows.

-- 
Paul Beardsell                          SAM Business Systems Ltd
~~~~~~~~~~~~~~                          21 Finn House, Bevenden St,
pbeardsell_at_cix.compulink.co.uk          London, N1-6BN, UK.
psb_at_sambusys.demon.co.uk                (+44 or 0)71 608-2391