http://bugzilla.slf4j.org/show_bug.cgi?id=176 Timofey Basanov <timofey.basanov@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |timofey.basanov@gmail.com --- Comment #4 from Timofey Basanov <timofey.basanov@gmail.com> 2011-06-24 08:58:31 CEST --- I would like to vote for this bug. I also get it during parallel unit-testing with TestNG. It took several hours of debugging before I understand the reason why it is happening. It made me really sad, because before of that slf4j was "just working" without the need to read through its internals. Thanks for such a good product BTW. I also would like to add that now slf4j code has data race due to incorrect access to shared variable. org.slf4j.LoggerFactory#INITIALIZATION_STATE could be easily accessed for read and write operations from multiple threads without synchronization primitives. According to JLS specification there are no guaranties from JVM on changes to state of such variable visible to other threads. Af far as I know the best way to fix this is to place synchronized(lock) guards around all places where you read or write to this variable. As far as I understand the code the simplest way to achieve this will be to place synchronized modifier onto org.slf4j.LoggerFactory#getILoggerFactory org.slf4j.LoggerFactory#reset and org.slf4j.LoggerFactory#failedBinding because they are the only public method. Cause creating fabric and not the logger should be pretty fast this will not impose any specific drawbacks for slf4j. This will also guarantee, that there will be no problems with order of synchronization for different threads which we are posing in this ticket. If this is not viable solution for some reason then I request to at least add volatile modificator for org.slf4j.LoggerFactory#INITIALIZATION_STATE to at least have a code that is written according to JLS requirements. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.