[slf4j-dev] [Bug 176] Initialization (getILoggerFactory) is not thread safe
bugzilla-daemon at pixie.qos.ch
bugzilla-daemon at pixie.qos.ch
Fri Jun 24 08:58:32 CEST 2011
http://bugzilla.slf4j.org/show_bug.cgi?id=176
Timofey Basanov <timofey.basanov at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |timofey.basanov at gmail.com
--- Comment #4 from Timofey Basanov <timofey.basanov at 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.
More information about the slf4j-dev
mailing list