Re: Comments on the KSE option

On Tue, 2006-10-31 at 07:54 +1100, Peter Ross wrote:
On Mon, 30 Oct 2006, Massimo Lusetti wrote:

On Sat, 2006-10-28 at 20:47 +0100, Robert Watson wrote:

significantly slower than multi-process ones. Many programmers believe that
threading is necessarily faster than using multiple processors, so I think
we're fundamentally forced to deal with the way they do use them, rather than
how they should use them.

I'm in sync with your opinion but speaking from the point of view of a
programmer which use FreeBSD i would like to say that enforcing (or at
least try to) good understanding of issues and good programming practice
is a good thing(TM), so if FreeBSD as an O.S. and as a community try to
enforce me to have good programming attitudes i really would like to
follow that.

I'm not a kernel developer, and not even a 'real' developer, I am just a
sys admin who hopes to get the best from the OS. At the moment I am
responsible for a bunch of servers to run a homegrown Java application. So
sorry if my thoughts here sound a bit naive.

The way the JVM exposes the threads to the OS just seems as a "natural"
way to me, especially if you are program for more then one OS. I
understand it as "leave it to the OS to sort things out. It should know
how to use the resources".

I administrate SMP servers running a resource-hungry Java/tomcat app. The
JVM has several hundred threads, e.g. 100 for every DB connection in a
connection pool.

It is difficult to imagine that a thread, a "light-weight process" causes
more kernel congestion than a process. I doubt it is the programmer's
fault, I would think there is something wrong withg the implementation.

It really is not that hard to imagine -- just think of what needs to be
done when multiple threads of the same process executing on multiple CPU
are trying to do sbrk(2), open(2) or mmap(2) -- apart from usual
activity for the single threaded process you have to make sure that
characteristics of the process as the whole (break value, first
available file descriptor or available virtual address in the process
space) stay consistent. Then you have my all-time favorite -- signal
delivery to the threaded process. And then multithreaded process does
fork(2)...

What means fairness in this context? (Simplification here) I don't hope
that the sshd gets half of the CPU if I login. I just hope that I get a
share to type a kill command if necessary;-)

It might be presumptious of me to speak on the subject I don't
necessarily completely understand myself, but an impression I got from
this E-mail thread is that concept of "fairness" would differ
dramatically between application programmer trying to wring every drop
of performance from the single-purpose multi-CPU box and sysadmin
supporting multi-user/multi-application environment. What seem to be
perfectly "fair" to the former is completely "unfair" to the latter.

Conversely, I think it is unfair to make me break my single-process
multi-threaded application into multiple communicating processes to
achieve performance gain (true story, not FreeBSD though ;)

--
Alexandre "Sunny" Kovalenko

_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: 10 ten things any good programmer can/has done?
    ... > For example, every good programmer should know how to parse, so every ... My thought is that if you work in multiple languages, ... dictionaries and archives (multiple files). ... multiple software development projects. ...
    (comp.programming)
  • Re: Other partitions missing after format of extended partition.
    ... BTW the reason I have split my hdd up like that is because I am a ... programmer and I require multiple O.S. and data that is easier managed ...
    (microsoft.public.win2000.general)
  • Feature Request: Selecting a word inside multiple words.
    ... It would be handy if the programmer can select a word inside these multiple ... I think this feature would be much more handy then selecting just all words. ...
    (alt.comp.lang.borland-delphi)
  • Re: Composite. Again!
    ... > Now the programmer can choose. ... He can put several views into a window, ... I would wait implementing the "multiple views per window" approach ...
    (comp.object)
  • Re: Intel Inside!!!
    ... a multi-CPU set-up will help you run ... >other things at the same time, or multiple instances. ... And the main reason for that finally happening is that ... It's still possible for a program to hog a fast CPU, ...
    (uk.comp.sys.mac)