[Mono-bugs] [Bug 497848] New: ReaderWriterLock: ReaderLocks do not appear to block WriterLocks

[bugzilla_noreply at novell.com]

http://bugzilla.novell.com/show_bug.cgi?id=497848


           Summary: ReaderWriterLock: ReaderLocks do not appear to block
                    WriterLocks
    Classification: Mono
           Product: Mono: Class Libraries
           Version: 2.0.x
          Platform: x86-64
        OS/Version: openSUSE 11.1
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: System
        AssignedTo: mono-bugs at lists.ximian.com
        ReportedBy: charlesb770 at yahoo.com
         QAContact: mono-bugs at lists.ximian.com
          Found By: ---


Created an attachment (id=287943)
 --> (http://bugzilla.novell.com/attachment.cgi?id=287943)
An nunit test with failing test: TestReadLockBlocksWrites

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.8)
Gecko/2009032600 SUSE/3.0.8-1.1.1 Firefox/3.0.8

When I have one thread use ReaderWriterLock.AcquireReaderLock followed by
another thread which uses ReaderWriterLock.AcquireWriterLock, the writer lock
is granted immediately.

In MS .Net 3.5 (VS2008) this is not the observed behavior. The WriterLock
should not be granted until the ReaderLock is released.

This seems to be a major bug; dirty reads are unavoidable in this state. This
class does not do what it is supposed to do.

I have attached an nunit testfixture which reproduces the issue. I have run
this test in VS2008 and it passes.

Reproducible: Always

Steps to Reproduce:
1.Start a thread that acquires a ReaderLock
2.Start a thread that acquires a WriterLock on the same resource

Actual Results:  
WriterLock is granted immediately

Expected Results:  
WriterLock should wait until the ReaderLock is released

-- 
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.