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

"Hans Forbrich" <forbrich_at_telusplanet.net> wrote in message news:3EBD1EFC.E53B5DD0_at_telusplanet.net...
> 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.
>
>
>

Could you recommend a good database theory book? Im familiar with threads from java and the wait,notify,synchronize interprocess stuff. I know unix has pthreads which appear to do the same thing and Solaris has a C interface for Mutex locks that seem to be generic.

Im in school, so preferably something academic that they might have in a university library. That way I dont have to pay for it... Im curious about OS theory.

Thanks. Received on Sat May 10 2003 - 11:42:38 CDT