«

Babu Kalakrishnan wrote:
>> Is it running on a computer with a lot of processors? otherwise, using
>> many threads is just a waste of CPU time.

> Not necessarily. Consider a case when each thread is waiting for some inputs
> that would arrive at some indeterminate time. Processing in parallel instead of
> serially would allow the inputs that arrived to be processed while other threads
> (probably started first) are still waiting.

True, but it seems pretty clear that this is not such a case.

Gary J wrote:
> In this case it is indeed running on a multi-processor computer. Running
> without multiple threads takes about 120% longer than running with them.
> The more threads, the faster it runs. There's probably a point of
> diminishing returns of course.

If the problem is purely CPU-bound, then this point should be reached exactly
when the number of threads equals the number of processors, if not earlier
(if the threads have to synchronize a lot, see Amdahl's law).

Michael Borgwardt wrote:

> Is it running on a computer with a lot of processors? otherwise, using
> many threads is just a waste of CPU time.

Just for interest: this is not necessarily true even for compute-bound
algorithms.

Consider the case where there are two techniques for solving a given problem,
one is slow but is guaranteed to find the correct answer, the other is 10 times
faster but only gets the right answer about half the time (and the other cases
are easily detectable /after/ they've failed but are hard to recognise in
advance). In that case, attempting to solve the problem using two threads (one
for each technique) will reduce the average time to produce an answer to about
65%, plus the overhead of the extra thread and thread switching. Obviously
this can be generalised; for instance the analysis is essentially the same if
you have different techniques that all always work, but are fast in different
cases.

That's just for academic interest -- I don't think I've ever encountered such a
situation in a real application.

-- chris

Gary J wrote:

> The problem is that in traversing a tree threads are created and finished
> the time which means the contents of the Collection would constantly
> change.

Hmm, then that is actually a different problem -- you are not trying to wait
for threads to finish, you are trying to detect when <something else> has
/stopped/ creating new threads.

There are loads of ways of doing that. If I had that kind of system, then my
first idea would be to handle it by introducing the simple convention that any
thread that started another thread had to join() with it before dying itself.

If that doesn't work for you, then the kinds of counting solutions that have
been discussed earlier are an option. I've rather lost track of where the rest
of the thread has got to, are you happy that you now know how to do that ?

BTW, do take the warnings about not expecting magic from threads seriously --
it sounds to me as if you may be overdoing the threading thing (unless this is
some sort of academic exercise).

-- chris

Gary J wrote:

> You're absolutely correct.
>
> When I initially saw the join() method I thought my problems were over but I
> discovered a possible problem with that approach.
>
> The problem is that in traversing a tree threads are created and finished
> the time which means the contents of the Collection would constantly change.
> The main method would have to constantly recheck and join to all the threads
> in the list on every pass until there were no more threads to join to. At
> that point I'm really doing the same thing as checking a counter but with
> more work
>
> Of course I could be mistaken and haven't tried this one out yet. There's
> probably a flaw in my logic.

Apply the join() technique in each thread that starts threads. Each
thread will have its own collection of the Threads it started, which
will not change once that thread stops creating new Threads and starts
join()ing the ones it created.


John Bollinger

Concurrency is way of structuring programs. It's not really related
to the number of CPUs. Some languages like java make this costly.
Other languages like erlang do not.

Michael Borgwardt wrote:
> Gary J wrote:
>
>> I have a java program that spawns a lot of threads to process a very
>> large
>> tree data model.
>
>
> Is it running on a computer with a lot of processors? otherwise, using many
> threads is just a waste of CPU time.

"thoff" <> wrote in message
news:...
> Michael Borgwardt wrote:
> > Gary J wrote:
> >
> >> I have a java program that spawns a lot of threads to process a very
> >> large
> >> tree data model.
> >
> >
> > Is it running on a computer with a lot of processors? otherwise, using many
> > threads is just a waste of CPU time.
> Concurrency is way of structuring programs. It's not really related
> to the number of CPUs. Some languages like java make this costly.
> Other languages like erlang do not.
>

Even on uni-processors, if the threads are using
I/O, then concurrency can help tremendously. Those
threads are "working" will get service while the
other threads that are "waiting" on I/O won't impact
the application through-put.

Note that I/O also includes virtual paging on
most systems. However, there is little that a
Java application can do to isolate its virtual
storage usage (thread local storage comes to
mind, but most folks rarely use that).

thoff wrote:

> Concurrency is way of structuring programs. It's not really related
> to the number of CPUs. Some languages like java make this costly.
> Other languages like erlang do not.

It's not really a language issue, as such. It'd be perfectly possible to
create a Java implementation (or JVM) where threads were as lightweight as in
Erlang.

The implementors have a choice in this matter. At one extreme they can
implement Java threads as real OS-level threads, which on most OSes is going to
mean that threads are heavyweight things. That has the considerable advantage
that Java programs are then using the same implementation of concurrency as any
other code (e.g. system calls only block the one thread, the OS can maps
threads to CPUs, threaded external libraries work as expected, ...). At the
other extreme the implementors can go for very lightweight threads; that would
lose the advantages of "real" OS threads, but enable (for instance) an
Erlang-style of programming with many small threads (and be a /good deal/
easier to implement, too).

To some extent the decision will reflect what programmers are actually /doing/
with threads, and that in turn will depend on programmers' expectations of how
threads are implemented. The Java programming community seems to have settled
on an expectation that threads are heavyweight, and so it makes sense for JVM
designers to optimise for the resulting patterns of usage.

(In any case, I'm not convinced that the Erlang way of programming with
micro-threads would work so well without Erlang's "share nothing" semantics, or
something similar.)

(Of course, all this assumes that the OS's threads are not themselves
lightweight, and it also assumes that a hybrid model with both lightweight and
heavyweight flavours of threads would be infeasible.)

-- chris

Chris Uppal wrote:
> (In any case, I'm not convinced that the Erlang way of programming with
> micro-threads would work so well without Erlang's "share nothing" semantics, or
> something similar.)

That's why it's a program language issue. With a share nothing
model and a global heap for efficient message sends, mere mortals can
make concurrent programs work. Not something you can say about java.
I could make an actor model and i could say everyone don't touch stuff
in other actors, but it would never work as people will touch
stuff, even assuming that threads could be made efficient enough to
handle high levels of concurrency.

thoff wrote:

> > (In any case, I'm not convinced that the Erlang way of programming with
> > micro-threads would work so well without Erlang's "share nothing"
> > semantics, or something similar.)
>
> That's why it's a program language issue. With a share nothing
> model and a global heap for efficient message sends, mere mortals can
> make concurrent programs work. Not something you can say about java.

Fair point, I think.

-- chris