Re: Linux/Windows Universal Benchmark
On Sat, Dec 01, 2001 at 02:38:51PM +0000, Shri Shrikumar wrote:
| > No, of course not. Different systems do different things well and
| > poorly. For example: Write a "benchmark" that starts and stops 10,000
| > processes and Linux will beat Windows hands-down. Write a "benchmark"
| > that starts and stops 10,000 threads and Windows will beat Linux
| > hands-down (if it's not still running the process benchmark...).
|
| Ummmm.... out of curiosity, Why / how does windows beat Linux ? Is it
| technically very difficult / impossible to have an OS that does
| processes and threads very fast or has Linux CHOSEN to give more
| importance to processes than to threads and why ?
In linux native threads (as opposed to "green" or "user" threads which
have nothing to do with the kernel at all) are mapped onto processes.
Each thread has its own PID and if you run top or gtop you will see
each one listed separately (even though they all share the same
address space). For an example run xmms or galeon and look at top. I
imagine that one reason linux maps threads on to processes is to
simplify the scheduler -- all those entities appear the same so
threads don't need any special handling.
Threads are actually a controversial entity. I do quite a bit of java
programming, and threads are quite convenient, and even necessary for
maintaining responsiveness in a GUI. However threads are the cause of
more bugs than anything else. Threads are convenient because all
threads share the same address space, thus they can communicate very
simply by passing an object reference. The tradeoff is that the
programmer must worry about synchronization and timing. Periodically
the question arises in newsgroups "if I am in threada and I want to
stop (kill) threadb, how do I do it?". The answer is *you can't*.
The only way is to have a shared flag, and have threadb check it
periodically and terminate itself if the flag is set. To explain this
I switch to processes for a moment :
With processes, each process has its own address space and its own set
of resources. As you are surely aware you can kill any process ('kill
-KILL') without affecting other processes. (slightly simplified, if
they are communicating via a socket, etc, there will be side effects)
This is because of the separate address space, etc. When you kill a
process the kernel takes care of releasing the memory, closing files
and sockets, and releasing other resources.
With threads, though, they share the same resources thus there is no
way for the kernel (or any other program) to reliably clean up when
you want a thread killed.
Some programmers believe that threads should not be used at all, but
only processes that communicate via some sort of IPC. Those
programmers also believe that if your OS has processes that aren't
lightweight enough for that to be feasible, then it is a bug in your
OS; threads are not the right band-aid for the problem.
I'm not totally decided on the matter. I find threads to be
convenient, though I am certainly aware of the headaches they can
cause. I haven't done any IPC programing so I have no experience
there to compare the merits.
-D
--
Failure is not an option. It is bundled with the software.
Reply to: