Re: concurrency, threads and objects

From:

Thomas Fritsch <i.dont.like.spam@invalid.com>

Newsgroups:

comp.lang.java.programmer

Date:

Wed, 15 Nov 2006 15:48:52 GMT

Message-ID:

<newscache$gx3s8j$6tm$1@news.ops.de>

Tom Forsmo wrote:
[...]

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.

So, why not use the same ClassA object for all your 100 threads?
     Runnable r = new ClassA();
     for(int i=0; i<opt.getThreads(); i++) {
         thr[i] = new Thread(r);
         thr[i].start();
     }
But of course this approach depends on how careful your ClassA object
handles concurrent calls to its run() method.

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.

Not quite: a thread is actually much cheaper than a process.

This is where my perception clashes with java threads.

Well, having 100 objects may not be such a big thing as you suspect. A
Java Thread object is actually nothing more than a native OS thread and
a few more bytes (for its member variables).

--
Thomas