On Apr 1, 2013, at 5:03 AM, Dan Creswell <[email protected]> wrote:
> On 1 April 2013 09:24, Peter Firmstone <[email protected]> wrote: > >> Dan Creswell wrote: >> >>> On 1 April 2013 08:11, Peter Firmstone <[email protected]> wrote: >>> >>> >>> >>>> Food for thought: After our pending release, it might be an idea to make >>>> a combined effort to identify and address as many concurrency issues as >>>> possible, we need to modernize our implementation code so we stay >>>> relevant. >>>> >>>> An important task will be updating all our service implementations so >>>> they >>>> DON'T start threads during construction. >>>> >>>> >>>> >>>> >>> The ActiveObject pattern often does start threads at construction. I'd >>> like >>> to understand why that is such a problem for you? It surely isn't a big >>> deal for me but.... >>> >>> >>> >> >> It allows fields to be declared final, if a thread is started during >> construction the JMM makes no guarantee that thread will see the final >> state of that objects fields after construction completes. >> > > Not sure that's true, at least in JDK 7: > > http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4 One caution to remember, is that the JLS only applies to intra-thread observable behaviors. When concurrency comes into play, you have to stare at the JMM too, to work out what reorderings might actually be possible. Gregg Wonderly > "An action that starts a thread *synchronizes-with* the first action in the > thread it starts. " > > "Two actions can be ordered by a *happens-before* relationship. If one > action *happens-before* another, then the first is visible to and ordered > before the second. " > > "If an action *x* *synchronizes-with* a following action *y*, then we also > have *hb(x, y)*. " > > i.e. If thread A is doing construction and then starts another thread, > variable assignments prior will be visible to the newly created thread. > > That in turn means so long as all critical assignments are done prior to > starting that second thread, there's no problem? > > And if that's true, starting a thread in a constructor needn't be avoided, > merely done "carefully". Thus it would be sufficient to ensure all final > variables are assigned prior to thread starting, which isn't so hard to do > or assure. I guess my point is, yes there's some care required but outright > banning thread start() in constructors is overkill. > > ? > > >> This is important when that thread accesses fields in the constructed >> object. >> >> See: >> https://www.securecoding.cert.**org/confluence/display/java/** >> TSM03-J.+Do+not+publish+**partially+initialized+objects<https://www.securecoding.cert.org/confluence/display/java/TSM03-J.+Do+not+publish+partially+initialized+objects> >> https://www.securecoding.cert.**org/confluence/display/java/** >> TSM01-J.+Do+not+let+the+this+**reference+escape+during+** >> object+construction<https://www.securecoding.cert.org/confluence/display/java/TSM01-J.+Do+not+let+the+this+reference+escape+during+object+construction> >> >> This doesn't mean you can't start a thread during construction, but it >> does mean you must be very careful if you do; our old code isn't that >> careful. ;) >> >> Cheers, >> >> Peter. >>
