[slf4j-dev] [Bug 176] Initialization (getILoggerFactory) is not thread safe

bugzilla-daemon at qos.ch bugzilla-daemon at qos.ch
Mon Oct 21 18:50:27 CEST 2013


http://bugzilla.slf4j.org/show_bug.cgi?id=176

James R. Perkins <jperkins at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jperkins at redhat.com

--- Comment #26 from James R. Perkins <jperkins at redhat.com> ---
(In reply to comment #25)
> (In reply to comment #24)
> > Created attachment 101 [details]
> > Patch for thread-safety issues during binding
> > 
> > The patch uses the same test previously attached. The implementation is
> > slightly different than the other patch. I don't think the reentrancy
> > checking should be necessary, but I don't know if other bindings actually
> > invoke this method again.
> 
> > // If re-entrant, return the temp factory
> 
> You're making an assumption that it will be re-entrant using the same
> thread. There is no guarantee that this is the case. The binding may be
> calling arbitrary external code that blocks while it does some
> initialisation. This initialisation may be performed with multiple threads
> in parallel, and one of those threads may try to log something.

Sorry for the delayed comment, I just realized I wasn't added to the CC when
adding a comment... ...anyway

Yes, that is the assumption that's being made. If another thread is invoked
from the initialization that attempts to run initialization again, then it will
deadlock. That said, initialization probably shouldn't be doing that. If it
just returned the TEMP_FACTORY we'd be back in a similar position.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-dev/attachments/20131021/a774300f/attachment.html>


More information about the slf4j-dev mailing list