[
https://issues.apache.org/jira/browse/LOG4NET-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782338#action_12782338
]
Piers Williams commented on LOG4NET-232:
----------------------------------------
This is a real pain for us, because we are attempting to use Chess (MS
Research) to test for multithreaded behavoral correctness, and due to the
deprication of ReaderWriterLock, Chess doesn't support it (and throws
NotImplementedExceptions when it encounters it).
So we're having to come up with evil ways to strip out log4net from our code
under test. Unfortunately even when our log4net code path isn't exercised at
runtime, static class ctors in log4net give us grief. Much of this seems to
come down to LoggerManager hooking ProcessExit / DomainUnload in it's static
class ctor (which is pure evil by the way - why can't you just wait until the
first repository is created?), and it's in there that a ReaderWriterLock is
used when the repositories are shut down. I'm currently trying to unwire them
using reflection which is just horrible.
Looks like just a few changes to log4net.Util.ReaderWriterLock are all that's
needed...
> Use ReaderWriterLockSlim instead of ReaderWriterLock.
> -----------------------------------------------------
>
> Key: LOG4NET-232
> URL: https://issues.apache.org/jira/browse/LOG4NET-232
> Project: Log4net
> Issue Type: Improvement
> Affects Versions: 1.2.10
> Environment: Any
> Reporter: Aron Weiler
> Priority: Minor
>
> ReaderWriterLock should be replaced with ReaderWriterLockSlim according to
> Microsoft for performance and simplification reasons.
> MSDN:
> http://msdn.microsoft.com/en-us/library/system.threading.readerwriterlock.aspx
> The .NET Framework has two reader-writer locks, ReaderWriterLockSlim and
> ReaderWriterLock. ReaderWriterLockSlim is recommended for all new
> development. ReaderWriterLockSlim is similar to ReaderWriterLock, but it has
> simplified rules for recursion and for upgrading and downgrading lock state.
> ReaderWriterLockSlim avoids many cases of potential deadlock. In addition,
> the performance of ReaderWriterLockSlim is significantly better than
> ReaderWriterLock.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
