Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <10701573.421591285601253521.JavaMail.jira@thor>
Date: Mon, 27 Sep 2010 11:27:33 -0400 (EDT)
From: "Sebb (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (CLI-209) OptionBuilder is not thread-safe
In-Reply-To: <50778.421141285597653417.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CLI-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915331#action_12915331 ] 

Sebb commented on CLI-209:
--------------------------

In fact the OptionBuilder class would be very tricky (perhaps impossible) to make thread-safe. 
The code is at best serially re-usable. 

Even then, the second thread would need to ensure that reset() was called before starting to use the class, because the lack of synch. means that the static variables updated by one thread may not be published to the second thread - i.e. the second thread might see stale values even though the first thread called reset() as part of create(). And of course the threads would have to ensure that they took it in turns to use the class.

Note that Option is not thread-safe either (settters/getters not synch.), however if the Option instance is confined to a single thread it would be OK.

Many of the other classes are not thread-safe either, as they have mutable variables that aren't volatile or synch.
But if confined to a thread, they would be OK.

Unless the documentation says otherwise, it's not safe to assume that a lbrary is thread-safe.

But I agree that the OptionBuilder is a particular problem.

It could be fixed by using ThreadLocal for all the static variables. But is it worth the effort?

> OptionBuilder is not thread-safe
> --------------------------------
>
>                 Key: CLI-209
>                 URL: https://issues.apache.org/jira/browse/CLI-209
>             Project: Commons CLI
>          Issue Type: Bug
>          Components: CLI-1.x
>    Affects Versions: 1.0, 1.1, 1.2
>         Environment: Windows XP, Java 6
>            Reporter: Thomas Herre
>
> Class OptionBuilder is not thread-safe.
> It uses one OptionBuilder instance without synchronizing access to it.
> If more than one thread uses OptionBuilder, that can result in invalid Options (suppose a scheduler component).
> Don't know if this should be fixed. At least the Javadoc should mention the fact that the class is not thread-safe.
> As a workaround, use constructor of class Option.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.