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

.

Relevant Pages

  • Re: Segmentation fault in mallopt/malloc call
    ... >errors or at least make them easier to detect, but the cost ... >(in memory and in time) is often quite high, ... >reason such programmer-friendly features are often absent ...
    (comp.lang.c)
  • Re: Im building a new gaming PC, I was wondering if I could get some hints....
    ... The same memory modules will do. ... The reason I used the 4gb 2gb kit, is so that i wont waste money when ... because my motherboard only supports that kind... ... the 5 case fans, not fully needing to be annoying me all the time... ...
    (alt.comp.hardware.pc-homebuilt)
  • [PATCH -mm 1/5] Freezer: Document relationship with memory shrinking
    ... allocate memory after freeing it for the hibernation image, ... The majority of these are user space processes, but if any of the kernel threads ... The second reason is to prevent user space processes and some kernel threads ... +memory and we need to do that before ...
    (Linux-Kernel)
  • Re: [PATCH] Hugepages should be accounted as unevictable pages.
    ... I don't have any strong oppose reason, but I also don't have any strong ... I agree that hugepages are special in the sense that they are ... other locked memory. ... don't see a reason why should accounting not reflect that. ...
    (Linux-Kernel)
  • Re: Terrabites of storage
    ... one half of the clock, ... peripherals, a couple K of memory, and the aforementioned flash block. ... which is another reason there aren't any 6502-derived chips ... [neep neep neep. ...
    (rec.arts.sf.composition)