Re: help with huge memory consumption??

On Mar 4, 12:09 pm, phil-news-nos...@xxxxxxxx wrote:

One problem with threads is they are more likely to fragment the memory.
One reason is the concurrency where multiple threads are entangling in
time and interleaving their allocations (if in the same arena). If some
threads go away but others stay, then you have a jumbled collection of
allocated and free spaces in the heap. Compare that to a simple process
that extinguishes the whole virtual memory when it is done. And programs
designed with threads tend to be those that are long lived (a major desk
application) as opposed to really short ones (simple web CGI).

I don't buy this for three reasons:

1) The fragmentation is largely a result of the workload, now how you
handle it. For example, consider an instant messaging server. You
allocate memory for things like clients, messages, file transfers, and
the like when they happen in the outside world. You free them when
they're finished. This will fragment the same whether it's handled by
one thread or one hundred.

2) You claim the increased concurrency causes this fragmentation. If
so, this is not a cost of threads but a cost of increased concurrency.
Nothing about choosing to use threads requires you to increase
concurrency, and you would only do so if the benefits outweighed the
costs. There are many benefits to using threads other than making it
easier to increase concurrency should it be beneficial to do so, for
example, your whole server won't stall should your program experience
some unexpected blocking on file access or a page fault. (In
comparison to a poll-loop server. See point three if you're comparing
it to lots of little processes.)

3) It is very rare that one has a choice to write a long-lived
application or a short-lived one. For applications that are naturally
short-lived, it doesn't matter. For applications that are naturally
long-lived, you don't have a choice. I agree that if you can solve a
problem with short-lived (or intermediate-lived) processes, that is
often preferable to long-lived ones.

DS

.

Relevant Pages

  • Re: Are all Ruby built-in objects thread safe?
    ... because of the way the wrapping is done there is no need to test thread safety because - as long as the delegator ensures that all methods are wrapped in this way there is no chance of corrupting internal state. ... Another reason is that you vastly depend on the underlying machine ... Things aren't made easier by the fact that - concluding from postings I see on comp.lang.java.* newsgroups for example - few people seem to have a thorough understanding of concurrency and all the issues involved. ... Another item on the "makes it hard" list is the fact that most OO and procedural languages only have a very basic toolkit for concurrency control; while Java started out pretty good with built in "synchronized" it took until version 5 that they incorporated Doug Lea's concurrency utilities into the language's standard library and also into the EJB spec. ...
    (comp.lang.ruby)
  • Re: Concurrency in Ada Errata in word format not Post script format
    ... The reason simply is to be able to read it so that I can get what I though ... >> Does anyone know of a Word format of Concurrency in Ada errata? ... > choose word for their revisable format? ...
    (comp.lang.ada)
  • Re: Parent-Child Relationship Headaches (add new records) (VB 2003)
    ... My program is only a single user program (hence the reason for not ... using something other than Access) so the problem of concurrency isn't ... and I doubt I'd understand it (did some C and Java years ago, ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Concurrency in Ada Errata in word format not Post script format
    ... Is there reason to believe the authors of Concurrency in Ada would ... choose word for their revisable format? ...
    (comp.lang.ada)