commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Sclafani (JIRA)" <>
Subject [jira] Commented: (LANG-334) Enum is not thread-safe
Date Wed, 06 Jun 2007 20:57:26 GMT


Michael Sclafani commented on LANG-334:

Well, the bug description refers to two enum classes, but your test only uses one enum class,
so I'm completely unsurprised you didn't replicate the problem.

The bug is caused by one thread calling getEnum(A.class, 0) while another thread is initializing
B.class, and those two threads are excuting in such a way that the first thread is reading
the cEnumClasses map while the second thread is modifying the same map by registering the
mapping for B.class. If you use only one enum class, the bug won't be seen. If you use two
enum classes, but statically reference them so that both classes are initialized before getEnum()
is called, no bug. If you use two classes, or ten classes, or 10000 classes, but fail to overlap
the threads reading the map and writing the map in just the right (or wrong) way, no bug.

Unit testing isn't a great approach for testing synchronization problems since it's impossible
for the test to control the execution order, especially when the bug requires actual concurrency.
This bug cropped up when we started using new multi-core hardware. I could write a unit test
for you, but I wouldn't expect it to fail unless you had identical hardware and software.

> Enum is not thread-safe
> -----------------------
>                 Key: LANG-334
>                 URL:
>             Project: Commons Lang
>          Issue Type: Bug
>            Reporter: Michael Sclafani
>             Fix For: 2.3.1
>         Attachments:
> Enum uses no synchronization. Even if you assume that instances are only declared statically,
the cEnumClasses map is global and can be written to when a thread triggers static initialization
of B.class while some other thread is doing getEnumList(A.class). Unsynchronized access of
a map undergoing mutation is not thread-safe.
> This isn't theoretical. We're seeing ValuedEnum.getEnum(X.class, 0) return null after
returning the correct value over 100,000 times, and then return the correct value again on
the next invocation.

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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message