[concurrency-interest] Starting a Thread within a constructor, what can go wrong?

David Holmes davidcholmes at aapt.net.au
Sun Dec 12 16:14:24 EST 2010


Gregg,

Can you provide an actual test case that demonstrates this as there should
not be any difference between the two forms.

Thanks,
David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Gregg
> Wonderly
> Sent: Sunday, 12 December 2010 6:24 AM
> To: Joe Bowbeer
> Cc: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Starting a Thread within a
> constructor, what can go wrong?
>
>
> One of the more problematic patterns is doing
>
> public MyClass implements Runnable {
> 	private final SomeClass val = new SomeClass();
> 	public MyClass() {
> 		new Thread(this).start();
> 	}
> 	public void run() {
> 		val.doSomething();
> 	}
> }
>
> The initialized final value will not be visible until the
> constructor completes
> in my experience, and if you instead do
>
> public MyClass implements Runnable {
> 	private final SomeClass val;
> 	public MyClass() {
> 		val = new SomeClass();
> 		new Thread(this).start();
> 	}
> 	public void run() {
> 		val.doSomething();
> 	}
> }
>
> Then val is visible when the thread starts because of the happens
> before that
> was alluded to before.
>
> Gregg Wonderly
>
> On 12/10/2010 9:24 PM, Joe Bowbeer wrote:
> > Marco,
> >
> > In addition to the other excellent replies, I'll add my $0.02
> >
> > The original SwingWorker, which is a class designed for
> subclassing, started its
> > worker thread in its constructor and this led to many problems
> in practice.
> >
> > Another problem with starting a thread in a constructor is that
> it is not
> > expected.  My expectation is that a constructor merely creates.
>  If I want
> > action, I'll call a method.
> >
> > In addition, I would ask why you're even creating a thread?
> Consider creating a
> > task instead and using an executor.
>
> Executors are not always the best choice for "forever" threads.
> Although there
> are some interesting recovery patterns you can create using
> single thread executors.
>
> > On Fri, Dec 10, 2010 at 5:30 PM, Marco Villalobos wrote:
> >
> >     QUESTION:
> >
> >     Can somebody please give me guidance on how I could
> possibly create a
> >     suite of test cases that run in TestNG or JUnit that can prove the
> >     thread unsafeness of this bad practice?
> >
> >     BACKGROUND
> >
> >     I'm trying to convince my colleague that starting a thread within a
> >     constructor compromises thread safety.
> >
> >     I understand that, "publishing objects before they are fully
> >     constructed can compromise thread safety."
> >
> >     But I would like an elaboration on how it compromises thread safety?
> >
> >     I understand that publishing the "this" reference would break
> >     encapsulation, allowing other classes and threads to potentially
> >     change the state of my object in an unthread safe manner.
> >
> >     But more specifically, what are the side affects of an object not
> >     being fully constructed, yet published through a thread.start in a
> >     constructor.
> >
> >     Here is an example of how "not to do things".
> >
> >     public class DontDoThis {
> >
> >       public synchronized void mutateMe() {
> >           // ... I'm mutating this...
> >       }
> >
> >       public final Thread t;
> >
> >       public DontDoThis() {
> >           t = new Thread(new Runnable() {
> >               public void run() {
> >                   mutateMe();
> >               }
> >           });
> >           t.start();   //     BAD BAD BAD Don't do this.
> >       }
> >     }
> >
> >     Can somebody please give me guidance on how I could
> possibly create a
> >     suite of test cases that run in TestNG or JUnit that can prove the
> >     thread unsafeness of this bad practice?
> >
> >     I want to make a short presentation on the issue.  If I provide a
> >     compilable and running test case, that would be amazing :)
> >
> >     -Marco
> >
> >
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



More information about the Concurrency-interest mailing list