Re: difference between thread based and process based operating systems?

Ryan wrote:

> Good article. Thanks. So I take it that a process is self contained. A
> thread is general 'interleaved' and shares memory correct?

Self-contained, but not necessarily isolated. Unix has a lot of interprocess communication capabilities, including shared memory and semaphores - these generally MUST be set up for Oracle before being able to start an Oracle install.

As an simplified overview - process-based services make a complete copy of the program space & the data space and run the processes independantly. Thread based servers make a copy of the selected program space and data space that is identified by the thread start/end demarc. Threads, however, do have access rights back to the parent process' memory and thus can be said to share memory.

Since they do not need to initialize everything, threads tend to be much faster and can be said to share memory.

Basically the process-based operation is a 'fork', potentially followed by an 'exec' ... fork duplicates the process/memory space, exec then permits replacement of the entry point to start a different program within the original process space.

I've always preferred the term "light-weight process" to "thread" ... because it reminds me that there is little functional difference between the, both need to be created and approporiately malloc'd, but the thread is too light weight to exist outside the framework provided by the process.

> So if you run a thread in the background in Unix or use a pthread is it a
> seperate process? Same as a daemon? Which I believe is just a thread run
> with an '&' at the end correct?

You seem to confusing terms here again ...

A process can be run in foreground or background. A thread can only be run within the context of a process. However a process can create many threads.

A daemon is traditionally a process run in the background that is not intended to terminate. Generally it has additional safeguards built in to ensure that if it terminates, it gets restarted by some sort of watchdog. The best examples of daemons are intended to listen for events and spawn responses, traditionally new processes. For example, the inetd (inter net daemon) listens for internet service requests and starts processes, such as telnet or ftp, depending on the port.

The & is a shell directive telling the command (which is a process forked from the shell process) to execute in the background instead of the foreground.

> I have a question of how shared server works on unix. If its spawning a
> seperate process, how does it 'share' since processes seem to be self
> contained.

A shared server can work in several ways - as a threaded server; or by using IPC (interprocess communication) to commnicate between the processes; or by creating a 'virtual swap space' and rolling in and out contexts (memory requests) based on interrupts. It all depends on design - all variants are supported and have appropriate libraries. Received on Sat May 10 2003 - 10:52:41 CDT