ReaderWriterLock acquire timeout values ???

  • Thread starter Thread starter Julie
  • Start date Start date
J

Julie

According to the documentation for the Acquire methods on the
ReaderWriterLock class:

-1 Infinite.
0 No time-out.
0 The number of milliseconds to wait.
Click to expand...

http://msdn.microsoft.com/library/d...systemthreadingreaderwriterlockclasstopic.asp

Does someone want to explain to me the difference between -1 (infinite)
and 0 (no time-out)???

I've been using 0, but occasionally get a time-expired exception that
traces back to an attempted acquire ??? I thought 0 was /not/ supposed
to time out.

I've switched to Timeout.Infinite (-1) to see if that fixes the problem.
Regardless, I'd like to know the difference(s) between the two values.
 
Julie,

Infinite means that it will wait forever to acquire the lock. A timeout
of 0 means that it will try and acquire the lock, and if it can't do it
instantly, it will give you the timed out exception.

You might want to consider using something else than a ReaderWriterLock.
My tests show it is horrendously slow (about 6-7 times) and there are a few
comments in blogs out there indicating that there is a starvation issue with
it. This isn't scheduled to be fixed until .NET 3.0 as well.

My suggestion, use the lock statement. You will get better performance.

Hope this helps.
 
Nicholas said:
Julie,

Infinite means that it will wait forever to acquire the lock. A timeout
of 0 means that it will try and acquire the lock, and if it can't do it
instantly, it will give you the timed out exception.

You might want to consider using something else than a ReaderWriterLock.
My tests show it is horrendously slow (about 6-7 times) and there are a few
comments in blogs out there indicating that there is a starvation issue with
it. This isn't scheduled to be fixed until .NET 3.0 as well.

My suggestion, use the lock statement. You will get better performance.
Click to expand...

Thanks for the info on the timeout value, not at all intuitive from the
documentation.

Regarding ReaderWriterLock -- I've used lock in the past, but it is far
from self-documenting and doesn't serve well in a reader/writer environment.

By the way, when is Microsoft going to be broken up so that we
developers and consumers can actually get worthwhile products in a
timely manner?
 
Here is a fast reader/writer updated from Birrell's of MSR. Accounts for
writer starvation:

using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;

namespace Locks
{
/// <summary>
/// Condition Variable (CV) class.
/// </summary>
public class CV
{
private readonly object syncLock = new object(); // Internal lock.
private readonly object m; // The lock
associated with this CV.

public CV(object m)
{
lock ( syncLock )
{
this.m = m;
}
}

public void Wait()
{
bool enter = false;
try
{
lock ( syncLock )
{
Monitor.Exit(m);
enter = true;
Monitor.Wait(syncLock);
}
}
finally
{
if ( enter )
Monitor.Enter(m);
}
}

public void Pulse()
{
lock ( syncLock )
{
Monitor.Pulse(syncLock);
}
}

public void PulseAll()
{
lock ( syncLock )
{
Monitor.PulseAll(syncLock);
}
}
}

public sealed class RW
{
private readonly object syncRoot = new object(); // Internal
lock.
private int i = 0; // 0 or greater
means readers can pass; -1 is active writer.
private int readWaiters = 0; // Readers
waiting for writer to exit.
private int writeWaiters = 0; // Writers
waiting for writer lock.
private CV wQ; // Condition
variable.

public RW()
{
wQ = new CV(syncRoot);
}

/// <summary>
/// Gets a value indicating if a reader lock is held.
/// </summary>
public bool IsReaderLockHeld
{
get
{
lock ( syncRoot )
{
if ( i > 0 )
return true;
return false;
}
}
}

/// <summary>
/// Gets a value indicating if the writer lock is held.
/// </summary>
public bool IsWriterLockHeld
{
get
{
lock ( syncRoot )
{
if ( i < 0 )
return true;
return false;
}
}
}

/// <summary>
/// Aquires the writer lock.
/// </summary>
public void AcquireWriterLock()
{
lock ( syncRoot )
{
writeWaiters++;
while ( i != 0 )
wQ.Wait(); // Wait until existing writer frees the
lock.
writeWaiters--;
i = -1; // Thread has writer lock.
}
}

/// <summary>
/// Aquires a reader lock.
/// </summary>
public void AcquireReaderLock()
{
lock ( syncRoot )
{
readWaiters++;
// Defer to a writer (one time only) if one is waiting to
prevent writer starvation.
if ( writeWaiters > 0 )
{
wQ.Pulse();
Monitor.Wait(syncRoot);
}

while ( i < 0 )
Monitor.Wait(syncRoot);
readWaiters--;
i++;
}
}

/// <summary>
/// Releases the writer lock.
/// </summary>
public void ReleaseWriterLock()
{
bool doPulse = false;
lock ( syncRoot )
{
i = 0;
// Decide if we pulse a writer or readers.
if ( readWaiters > 0 )
{
Monitor.PulseAll(syncRoot); // If multiple readers
waiting, pulse them all.
}
else
{
doPulse = true;
}
}
if ( doPulse )
wQ.Pulse(); // Pulse one writer if one
waiting.
}

/// <summary>
/// Releases a reader lock.
/// </summary>
public void ReleaseReaderLock()
{
bool doPulse = false;
lock ( syncRoot )
{
i--;
if ( i == 0 )
doPulse = true;
}
if ( doPulse )
wQ.Pulse(); // Pulse one writer if one
waiting.
}
} // RW
}
By the way, when is Microsoft going to be broken up so that we developers
and consumers can actually get worthwhile products in a timely manner?
Click to expand...

I assume your kidding.

Cheers.
 
William said:
Here is a fast reader/writer updated from Birrell's of MSR. Accounts for
writer starvation:
Click to expand...

<snip>

Very much appreciated!
I assume your kidding.
Click to expand...

Not at all.

What foolishness in tying frameworks to operating system releases.

What foolishness in a dearth of service packs/fixes/anything for
development environments.

What foolishness in major re-writing of major applications each version.

Need I go on.

We, the end users, developers, and customers are *NOT* served by
Microsoft's current model.
 
Back
Top