Re: concurrency, threads and objects
Chris Uppal wrote:
I can't think of any reason why setName() wouldn't work. I admit I haven't
tested it, but I can't see anything odd in the source. I suspect that it's an
artefact of whatever you are using to "see" the Thread's names.
I use println() just before start(), and then another println() inside
run() to print the progress of each thread. When I print before start()
it prints out the name I set, but when I print inside run() the name is
reset to the original name. Its almost as if there is an object
reinitialisation when run starts.
But why use setName() at all ? It seems easier just to pass the correct names
to the Threads' constructors in the first place.
I haven't tried that, it might work.
If I use 100
threads, I would create 100 ClassA objects, which means I would have 100
ClassA objects and 100 Thread objects.
So what ?
I don't believe in code bloat and I see it as unnecessary runtime
resource consumption. I don't subscribe to the idea that you should not
worry about resources (cpu, memory etc.), because its so cheap. The
reason is simple, bloated code runs slower and is more difficult to
maintain. Think of a program that takes up 300 MB of memory and compare
it to a program that only requires say, 150MB. The smaller program
requires less bus bandwidth between the cpu, memory and disk and less
processing cycles (barring algorithm efficiency).
I do see, though, that there are solutions where doing having one object
per thread is beneficial. But it sort of leaves a bad taste in my mouth...
Think of it like this. If those 100 objects which implement Runnable are
genuinely unnecessary, then they must be effectively stateless in that none of
the processing in any thread depends on the state of its Runnable object -- in
which case there is no reason not to use the same Runnable for every Thread.
But, going further, if they are /actually/ stateless, or nearly so, then they
are so cheap that they cost much less (in space and time) than the Thread
itself, and will almost certainly cost less even than the thread's /name/, so
there is no reason to go to the (cognitive) effort of reusing the same object.
Just create 100 of 'em -- you can afford it.
OTOH, if the Runnables' states /do/ affect the subsequent execution, then you
obviously can't get away without having separate objects...
BTW, the most common case is that each thread /is/ parameterised in some way
(which Socket to read from, which array to process, which Snoggle to
delaminate(), ....) and the Runnable objects are the natural place to put that
information.
I have come to the same conclusions as well. But as I said I think it
leaves a bad taste... But then again, I might just be a bit picky.
thanks for all your feedback.
tom