river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: code comment in TxnManagerImpl
Date Mon, 01 Apr 2013 10:03:10 GMT
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:


"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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message