Re: multithreading

In article <1994Nov23.162016.6226_at_cae.ca> michel_at_cae.ca "Michel Lagace" writes:

> Paul Beardsell (psb_at_sambusys.demon.co.uk) wrote:
>
> [stuff deleted]
>
> : Certainly Oracle implement 4 different processes on most platforms to
> : do different jobs. Each of those may have their own internal threading.
 

> : A criticism of Sybase may well be that everything is in threads. Some
> : tasks of the Sybase RDBMS are probably just crying out for the extra
> : throughput they might get from being in their own process.
>
> One thing is clear, a task *cannot* get more throughput by being in its
> own process.

This is not true. There are two ways of implementing threads. With and without kernel support. Most Unix's do not have kernel support for threads. On such a (busy) machine where there are 100, say, processes & one of them is multi-threaded with ten threads, each of the threads will have 1/10th of the CPU allocated to it on average as each of the 99 other processes. And I have not counted the cycles stolen by the thread scheduler running inside the threaded process. Re-writing the threaded process as ten processes will give each almost a magnitude more CPU. So: For your statement to be true we would need kernel support for threads and also a clever scheduler.

> Threads, like processes, compete for a computer's resources.
> The major difference between a process and a thread is that a thread does
> not have to switch a full process context in order to relinquish the CPU
> to another thread.

How can it? You are right by definition! Of course a process context switch is not required to switch threads. On a machine with kernel support for threads we would still require a user->kernel->user mode switch for a thread context switch. What saving is there here over a process context switch? So: For your statement to be true we require threading without kernel support.

> In fact, the _throughput_ of tasks fully implemented in
> threads will always be better (if well implemented) than tasks implemented
> as processes.

Despite the fact that for threading to have a hope in hell of being all you claim it to be it must both HAVE and NOT HAVE kernel support it might surprise you to actually do the sums and count the clock cycles and the memory used: On Unix thread vs process context-switching performance is not as clear-cut an issue as you might think.

> The reason for a DBMS vendor to use processes instead of threads is that
> the code is easier to implement as a series of processes. Threads are
> harder to use and ask for more discipline on the part of the software
> engineer using them. The choice of processes over threads is usually
> (if not always) a question ofdelivery schedules and not one of perfor-
> mance.

These are complicated issues that disserve more than a paragraph before coming to your conclusion. I am VERY interested in whether readers consider multi-process or multi-threaded development easier.

> --
> Michel Lagace _at_ CAE Electronics ltd.
> PO Box 1800 | Phone: (514)341-6780 X-3236
> St-Laurent, Quebec | Fax: (514)340-5496
> Canada H4L 4X4 | email: michel_at_cae.ca
 

-- 
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