[
https://issues.apache.org/jira/browse/BCEL-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14935916#comment-14935916
]
Stephan Herrmann commented on BCEL-267:
---------------------------------------
{code}However, at this point in time there are no plans to support
multi-threaded use of BCEL.{code}
I'd like to ask you to reconsider this, because we might be talking about two
different levels of support for multi-threading.
I understand that two threads simultaneously working *on the same data* can
cause arbitrary havoc and making BCEL safe against this kind of usage is
probably hard, agreed.
In my use-case, however, the clients of BCEL already ensure, that never two
threads operate on the same class files / data structures of BCEL. Still the
bogus use of a static field makes it impossible that two threads ever use BCEL
concurrently *even on 100% disjoint data*. I don't think it is reasonable to
burden clients so much as to prevent even these completely isolated calls into
BCEL.
Please see that this style of concurrency was impossible with original BCEL and
never again caused any concurrency issues after my tiny changes have been
applied.
In order to protect against this style of concurrency, we would need a *single,
global* lock in front of every call into BCEL, which is not feasible.
I believe a static mutable field with no protection is reason enough for fixing
under any circumstances :)
> Race conditions on static fields in BranchHandle and InstructionHandle
> ----------------------------------------------------------------------
>
> Key: BCEL-267
> URL: https://issues.apache.org/jira/browse/BCEL-267
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
> Affects Versions: 5.2
> Reporter: Stephan Herrmann
>
> I have observed race conditions causing NullPointerException like this
> {code}java.lang.NullPointerException
> at
> org.apache.bcel.generic.InstructionList.getInstructionHandles(InstructionList.java:1021)
> at
> org.apache.bcel.generic.InstructionList.findHandle(InstructionList.java:141)
> at org.apache.bcel.generic.MethodGen.<init>(MethodGen.java:194)
> {code}
> In the debugger I could verify that concurrent access to the fields
> {{BranchHandle.bh_list}} or {{InstructionHandle.ih_list}} can cause
> corruption of those lists.
> I succeeded to make the exception less frequent by adding synchronized
> blocks, but still the exception could be observed. I concluded that for safe
> protection the fields would need to be made volatile, which in the end might
> actually defeat their original purpose of optimization.
> I have since then run with a patched version of BCEL, where those static
> fields were simply removed and new Handles were created on every request.
> This variant finally was free of the race condition.
> Seeing activity towards a 6.0 release, I'd appreciate if this change could be
> incorporated.
> The original bug tracking my experiments can be found in Eclipse bugzilla:
> https://bugs.eclipse.org/344350
> The modified classes (based on 5.2) can be found here:
> -
> http://git.eclipse.org/c/objectteams/org.eclipse.objectteams.git/tree/plugins/org.eclipse.objectteams.otre/bcelpatchsrc/org/apache/bcel/generic
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
