river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: code comment in TxnManagerImpl
Date Tue, 02 Apr 2013 01:04:50 GMT

On Apr 1, 2013, at 5:03 AM, Dan Creswell <dan.creswell@gmail.com> wrote:

> On 1 April 2013 09:24, Peter Firmstone <jini@zeus.net.au> wrote:
> 
>> Dan Creswell wrote:
>> 
>>> On 1 April 2013 08:11, Peter Firmstone <jini@zeus.net.au> 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.
>> 


Mime
View raw message