Re: concurrency, threads and objects
On 15.11.2006 16:07, Tom Forsmo wrote:
Sorry, what I meant was my defined objects, not the Thread objects. E.g.
I can define an class ClassA which implements Runnable. If I use 100
threads, I would create 100 ClassA objects, which means I would have 100
ClassA objects and 100 Thread objects.
thr = new Thread[opt.getThreads()];
for(int i=0; i<opt.getThreads(); i++) {
Runnable r = new ClassA();
thr[i] = new Thread(r);
thr[i].start();
}
Of course the Thread object is here composed of the ClassA object, so it
would be the same as if you extended a Thread class, but that is my
point. It seems like a waste of resources to have those 100 ClassA
objects lying around for no reason.
As said earlier, the overhead of a single object is not much. And the
advantage of using a class that implements Runnable is that you get more
flexibility. You can, for example, push those instances into a queue
and have a fixed number of threads processing them one by one. (I think
Doug calls it "lightweight processing framework".)
> A thread safe program requires
re-entrancy, which it in this example solves, not by having a re-entrant
object, but rather by just creating completely new objects avoiding the
entire issue... Sort of like starting 100 separate programs/processes.
This is where my perception clashes with java threads.
The concept is called "thread confinement" (-> Doug Lea's book).
Basically this means that you avoid congestion by having separate sets
of data which in turn removes the necessity of synchronization.
Whether you apply that or not depends on the circumstances. Also of
course this can be mixed with other approaches so you get very precise
control over which data is shared and which not.
Regards
robert