On Apr 28, 2013, at 8:34 AM, Patricia Shanahan p...@acm.org wrote:
On 4/27/2013 4:19 PM, Peter Firmstone wrote:
...
But we are starting to encroach into territory where angels fear to
tread, requiring genius reasoning powers. For 99% of cases I'd like to
stick to simple rules that avoid
On 4/27/2013 4:19 PM, Peter Firmstone wrote:
...
But we are starting to encroach into territory where angels fear to
tread, requiring genius reasoning powers. For 99% of cases I'd like to
stick to simple rules that avoid reasoning about consequences of data
races. This will make it easier for
Ok found the link, the paper's called:
Position paper: Nondeterminism is unavoidable, but data races are
pure evil
http://www.hpl.hp.com/techreports/2012/HPL-2012-218.pdf
Wheather Thread's name field is an issue or not depends on the code that
uses it (Object.toString() and Thread.getName()
I also don't see the particular concern with toString(). It uses
getName(), so it does all its work with a particular char[]. At the
worst, that char[] will either be an old one, or the current one but
with some out-of-date elements, resulting in an unhelpful value.
Patricia
On 4/27/2013
Based on your reasoning and because all tests are passing reliably without
failure now, it should be safe to uncomment it.
Peter.
- Original message -
I also don't see the particular concern with toString(). It uses
getName(), so it does all its work with a particular char[]. At the
Discussion on the concurrency interest list touched briefly on the consequences of different threads calling
Thread.setName(), under these conditions it appears legal for hotspot to potentially reorder the operations in a way
that causes errors.
We can reason in ThreadPool's case, there is a
Yes, the important thing to understand, as shown in the text below, is that
setName is rewritten so that the array value is assigned to the visible
class member before the System.arrayCopy is performed. This can result in
different failure modes if setName is racing with getName. One of the
I've looked at the source code. The field name that is shared between
threads doing getName or setName on a given Thread is a reference.
Writes and reads of references are always atomic.
The worst that could happen is that the change to the name does not
propagate to all threads that might
