You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-dev@logging.apache.org by "Aron Weiler (JIRA)" <ji...@apache.org> on 2009/10/17 01:47:31 UTC

[jira] Created: (LOG4NET-232) Use ReaderWriterLockSlim instead of ReaderWriterLock.

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.

[jira] Commented: (LOG4NET-232) Use ReaderWriterLockSlim instead of ReaderWriterLock.

Posted by "Piers Williams (JIRA)" <ji...@apache.org>.
    [ 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.

[jira] Issue Comment Edited: (LOG4NET-232) Use ReaderWriterLockSlim instead of ReaderWriterLock.

Posted by "Piers Williams (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/LOG4NET-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851392#action_12851392 ] 

Piers Williams edited comment on LOG4NET-232 at 3/30/10 1:22 PM:
-----------------------------------------------------------------

Since ReaderWriterLockSlim is a .net 3.5 addition (in System.Core), building on .net 3.5 is required to fix this issue

See https://issues.apache.org/jira/browse/LOG4NET-176

      was (Author: piers7):
    Since ReaderWriterLockSlim is a .net 3.5 addition (in System.Core), building on .net 3.5 is required to fix this issue
  
> 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.