Lloyd L Chambers wrote:
> Bill,
>
> I ask the following because the response I'm getting for having filed
> about 40 GlassFish thread-safety bugs as P2 today has been neutral at
> best. All of them are easy to fix (most are the null-check idiom).
>
> I can't say whether they currently cause a problem, on what OS or system
> they might cause a problem, or even whether they'll *ever* cause or have
> caused a problem. But I can say there is an effort underway to thread
> GlassFish startup code, and that the code for most of these will be run
> at startup. I can also say I had to back out some changes I committed
> last Friday which mysteriously passed on two Mac OS X machines, but
> failed on Linux and Solaris--and I can't explain why.
>
> 1) If you came across a thread-safety issue, at what level would you
> file it? P1, P2, P3, P4?
There isn't a simple answer to this question.
In general, I would probably file thread safety bugs as P3, but there are
exceptions that could go higher or lower.
> 2) Would it depend on *when* it was found (eg just before beta)?
Generally I don't modify bug priorities based on when during the release
cycle the bug is found. Per normal Sun bug priority definitions, the
bug priority essentially tells you when the bug should be fixed. P3
needs to be fixed before FCS (final release).
> 3) Would the level depend on whether you could *prove* it was actually
> resulting in a reproducible bug?
Yes. That would certainly increase the priority.
> 4) Would it be acceptable to ship thread-unsafe code to a customer
> without knowing the answers to the above, especially if the fix is trivial?
I think the big qualifier is "the fix is trivial". I've made trivial
fixes that turned out to have unforeseen consequences, so some caution
is called for. But, in general, and especially earlier in a release
cycle, I would err on the side of fixing such bugs.
> We have been filing P2 bugs for performance improvements. I am troubled
> by the idea that a correctness bug can be a lower priority than a minor
> performance improvement goal. The unknown and unquantifiable risk of a
> thread-safety bug is compelling enough for me to make it a P2.
>
> I would appreciate your thoughts. If you would like to cc dev_at_glassfish,
> that is OK with me. Or if you prefer a private response, that's OK too.
>
> Lloyd
There's a lot of "it depends" in all of this.
When running FindBugs on the JavaMail code that I maintain, it found a
number of places where fields are only protected by locks some of the
time. In general, these are just accidents waiting to happen, and it
scares me. But, in most cases, the problems are in code that hasn't
changed in many years and such problems have never occurred in practice
(to my knowledge, of course). These are the kinds of bugs I would consider
to be P4 or lower. The risk of fixing such bugs in otherwise stable and
tested code is greater than the risk of the bug actually occurring.
No bug fix is risk free, and sometimes the probability of breaking
something while fixing the bug is greater than the probability of the
bug actually occurring.
In cases where I judge the risk to be too great, I often add a comment
to the code describing the problem and the risk, in case I decide in
the future that the fix is less risky or the bug more likely.
Hope that helps.