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

"Ryan" <rgaffuri_at_cox.net> wrote in message news:25Wua.43841$g41.4001422_at_news1.east.cox.net...
> >
> > I've heard rumours that Oracle 10 will be threaded for unix'es that
> > support it....dunno if thats just talk though
> >

Wouldn't surprise me. Threading in Unix is getting more usable. It was quite inneficient (and a bit flaky) a few years ago. But threading is potentially better for a database server than multi-process. A lot less overhead in memory control too. As I said: won't surprise me one bit.

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

In general yes. A thread is just a section of code in a process that runs concurrently with any other threads of the same process. The process may control the scheduling of its threads or may ask the OS to manage it.

All processes have at least one "thread" in a multi-thread OS. They can create more. All threads of a process will run concurrently from the same address space as the process and all can access the same data segments.

In Windows NT you can watch threads and processes using the Task Manager processes display and asking for columns relating to threads to be shown. They aren't by default. In Unix, there are all sorts of monitors that show all these relationships quite well.

Of course restrictions can be imposed on this data segment access, but we're getting into other territories: in modern implementations, you can even impose memory access boundaries for each thread and enjoy full hardware memory protection between threads. Although this somewhat defeats the purpose of multi-threading as a "light-weight" multi-process mechanism.

>
> So if you run a thread in the background in Unix or use a pthread is it a
> seperate process?

You have to have a process to have one thread running. They don't exist by themselves. Think of it as a hierarchy: a process can have one or more threads. But a thread does not exist by itself: it has to be part of a process.

> Same as a daemon?

Not quite. Daemons are processes that have been identified to Unix as so. There is a specific call to do that. As a result, they are treated by the scheduler and init() in a slightly different way and Unix does not associate a default standard input and output stream with them. Other than that, daemons are just like any other program: they can be single-threaded or multi-threaded when run.

> Which I believe is just a thread run
> with an '&' at the end correct?
>

not at all. "&" is a shell convention to start a program in "background". Which essentially means "batch". Or non-interactive, if you prefer. But the program still gets a standard input and output stream associated with it, it just comes/goes from/to disk instead of the screen. If you so ask. Do not confuse thread with process. A process can contain one or more threads, but a thread does not exist without a parent process.

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

Cripes, this is bringing back memories from my days doing OS support! :D

Processes in Unix running from the same executable file share the same copy of code in memory but each receives a different data segment and each has its code segment mapped to a different address space.

They can also access "shared memory". This is requested off Unix using the shmem() library call. Unix then makes a "chunk" of memory (one or more data segments) of the asked size accessible to the address space of any processes requesting it. As such a number of processes may access this data segment(s) memory concurrently. Hence the "shared" name.

What is shared is the named shared data segment(s). Not the stack space of each process or any other data segments each may have. So the self-contained nature of a process is preserved, but a portion of data segment memory is shared with other processes. Mechanisms such as semaphores and P-V operations are used to synchronize this access and make sure processes don't trample all over each other when accessing critical sections of data.

Ever heard of Oracle latches? They are used for this synch process: they are a faster mechanism than full blown semaphores. And spin locks too. And so on.

Fascinating stuff, if you feel so inclined. There are heaps of materials on this accessible on the Internet, do some searches and you'll find oodles of good karma. Tannenbaum is the book author that deals mostly with this. Dijkstra did too and IMHO much better, but his books are hard to find. There is a collection of all of his papers on the Internet and that is one of the best resources for study of OS technology and theory one could ever hope for. Priceless. Knuth also has a lot on memory control and data structures.

Be careful about some of the Java-related material: they make some short cuts in defining threads and processes and in their world things don't quite map to the same as in the OS world. Don't forget the VM replaces the OS somewhat. Hence they don't have to obey the same restrictions of a full blown multi-processing general purpose OS.

--
Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au