Review Request: CR 7100996 - (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads (original) (raw)

Doug Lea dl at cs.oswego.edu
Thu Jun 21 16:15:37 UTC 2012

On 06/21/12 11:59, Jim Gish wrote:

Please review the proposed spec change to StringBuffer below, which informs the user about additional thread safety issues as described in the bug. (Thanks to Brian for the language).

Brian: Nice wording! It misses mentioning the constructor StringBuffer(CharSequence seq) case though.

Perhaps change: multiple threads, the source data passed to append/insert, if shared to multiple threads, the source data passed to create/append/insert, if shared

With this change, the paragraph could also be readily adapted to also be placed in class java.util.Vector, that infamously has similar issues. (For which I suspect there is some CR).

... and possibly further adapted in some other Collection methods when they are next updated for other reasons.

-Doug

Thanks, Jim diff -r 46ff1b63b0c3 src/share/classes/java/lang/StringBuffer.java --- a/src/share/classes/java/lang/StringBuffer.java Mon Jun 11 07:10:48 2012 -0400 +++ b/src/share/classes/java/lang/StringBuffer.java Thu Jun 21 11:45:51 2012 -0400 @@ -63,6 +63,14 @@ * appending or inserting from a source sequence) this class synchronizes * only on the string buffer performing the operation, not on the source. *

+ * While StringBuffer is designed to be safe to use concurrently from + * multiple threads, the source data passed to append/insert, if shared + * across threads, must ensure that StringBuffer.add/insert has a + * consistent and unchanging view of the source data for the duration of + * the operation. This could be done by the caller holding a lock during + * the add/insert call, or because the source data is immutable, or because + * the source data is not shared across threads. + *

* Every string buffer has a capacity. As long as the length of the * character sequence contained in the string buffer does not exceed * the capacity, it is not necessary to allocate a new internal

More information about the core-libs-dev mailing list