Develop Reference

Is there a version of Semaphore Slim or another method that will let the same thread in downstream?

I am refactoring older synchronous C# code to use an async library. The current synchronous code makes liberal usage of locks. Outer methods often call inner methods, where both lock on the same objects. These are often "protected objects" defined in the base class and locked upon in base virtual methods and the overrides that call the base. For synchronous code, that's ok as the thread entering the outer/override method lock can also enter the inner/base method one. That is not the case for async / SemaphoreSlim(1,1)s.
I'm looking for a robust locking mechanism I can use in the async world that will allow subsequent downstream calls to the same locking object, to enter the lock, as per the behaviour in synchronous "lock {...}" syntax. The closest I have come is semaphore slim, but it is too restrictive for my needs. It restricts access not only to other threads, but to the same thread requesting entrance in the inner call too. Alternatively, is there a way to know that the thread is already "inside" the semaphore before calling the inner SemaphoreSlim.waitasync()?
Answers questioning the design structure of the inner/outer methods both locking on the same object are welcome (I question it myself!), but if so please propose alternative options. I have thought of only using private SemaphoreSlim(1,1)s, and having inheritors of the base class use their own private semaphores. But it gets tricky to manage quite quickly.
Sync Example: Because the same thread is requesting entrance to the lock in both inner and outer, it lets it in and the method can complete.
private object LockObject = new object();
public void Outer()
{
lock (LockObject)
{
foreach (var item in collection)
{
Inner(item);
}
}
}
public void Inner(string item)
{
lock (LockObject)
{
DoWork(item);
}
}
Async Example: The semaphore doesn't work like that, it will get stuck at the first iteration of inner async because it's just a signal, it doesn't let another one pass until it is released, even if the same thread requests it
protected SemaphoreSlim LockObjectAsync = new SemaphoreSlim(1,1);
public async Task OuterAsync()
{
try
{
await LockObjectAsync.WaitAsync();
foreach (var item in collection)
{
await InnerAsync(item);
}
}
finally
{
LockObjectAsync.Release();
}
}
public async Task InnerAsync(string item)
{
try
{
await LockObjectAsync.WaitAsync();
DoWork(item);
}
finally
{
LockObjectAsync.Release();
}
}

I am in full agreement with Servy here:
Reentrancy like this should generally be avoided even in synchronous code (it usually makes it easier to make mistakes).
Here's a blog post on the subject I wrote a while ago. Kinda long-winded; sorry.
I'm looking for a robust locking mechanism I can use in the async world that will allow subsequent downstream calls to the same locking object, to enter the lock, as per the behaviour in synchronous "lock {...}" syntax.
TL;DR: There isn't one.
Longer answer: An implementation exists, but I wouldn't use the word "robust".
My recommended solution is to refactor first so that the code no longer depends on lock re-entrancy. Make the existing code use SemaphoreSlim (with synchronous Waits) instead of lock.
This refactoring isn't extremely straightforward, but a pattern I like to use is to refactor the "inner" methods into private (or protected if necessary) implementation methods that are always executed under lock. I strongly recommend these inner methods follow a naming convention; I tend to use the ugly-but-in-your-face _UnderLock. Using your example code this would look like:
private object LockObject = new();
public void Outer()
{
lock (LockObject)
{
foreach (var item in collection)
{
Inner_UnderLock(item);
}
}
}
public void Inner(string item)
{
lock (LockObject)
{
Inner_UnderLock(item);
}
}
private void Inner_UnderLock(string item)
{
DoWork(item);
}
This gets more complex if there are multiple locks, but for simple cases this refactoring works well. Then you can replace the reentrant locks with non-reentrant SemaphoreSlims:
private SemaphoreSlim LockObject = new(1);
public void Outer()
{
LockObject.Wait();
try
{
foreach (var item in collection)
{
Inner_UnderLock(item);
}
}
finally
{
LockObject.Release();
}
}
public void Inner(string item)
{
LockObject.Wait();
try
{
Inner_UnderLock(item);
}
finally
{
LockObject.Release();
}
}
private void Inner_UnderLock(string item)
{
DoWork(item);
}
If you have many of these methods, look into writing a little extension method for SemaphoreSlim that returns IDisposable, and then you end up with using blocks that look more similar to the old lock blocks instead of having try/finally everywhere.
The not-recommended solution:
As canton7 suspected, an asynchronous recursive lock is possible, and I have written one. However, that code has never been published nor supported, nor will it ever be. It hasn't been proven in production or even fully tested. But it does, technically, exist.

How to prevent a method from running across multiple threads?

I am working on a web application, where several users can update the same record. So to avoid a problem if users are updating the same record at the same time, I am saving their changes in a queue. When each save occurs, I want to call a method that processes the queue on another thread, but I need to make sure that the method cannot run in another thread if it is called again. I’ve read several posts on the subject, but not sure what is best for my situation. Below is the code I have now. Is this the correct way to handle it?
public static class Queue {
static volatile bool isProcessing;
static volatile object locker = new Object();
public static void Process() {
lock (locker) {
if (!isProcessing) {
isProcessing = true;
//Process Queue...
isProcessing = false;
}
}
}
}

New answer
If you are persisting these records to a database (or data files, or similar persistence system) you should let that underlying system handle the synchronization. As JohnSaunders pointed out Databases already handle simultaneous updates.
Given you want to persist the records… the problem presented by John is that you are only synchronizing the access to the data in a single instance of the web application. Still, there could be multiple instances running at the same time (for example in a server farm, which may be a good idea if you have high traffic). In this scenario using a queue to prevent simultaneous writes is not good enough because there is still a race condition among the multiple instances of the web page.
In that case, when you get updates for the same record from different instances, then the underlying system will have to handle the collision anyway, yet it will not be able to do it reliably because the order of the updates has been lost.
In addition to that problem, if you are using this data structure as a cache, then it will provide incorrect data because it is not aware of the updates that happen in another instance.
With that said, for the scenarios where it may be worth to use a Thread-Safe Queue. For those cases you could use ConcurrentQueue (as I mention at the end of my original answer).
I'll keep my original answer, because I see value in helping understand the threading synchronization mechanism available in .NET (of which I present a few).
Original answer
Using lock is enough to prevent the access of multiple threads to a code segment at the same time (this is mutual exclusion).
Here I have commented out what you don't need:
public static class Queue {
// static volatile bool isProcessing;
static /*volatile*/ object locker = new Object();
public static void Process() {
lock (locker) {
// if (!isProcessing) {
// isProcessing = true;
//Process Queue...
// isProcessing = false;
// }
}
}
}
The lock does NOT need volatile to work. However you might still need the variable to be volatile due to other code not included here.
With that said, all the threads that try to enter in the lock will be waiting in a queue. Which as I understand is not what you want. Instead you want all the other threads to skip the block and leave only one do the work. This can be done with Monitor.TryEnter:
public static class Queue
{
static object locker = new Object();
public static void Process()
{
bool lockWasTaken = false;
try
{
if (Monitor.TryEnter(locker))
{
lockWasTaken = true;
//Process Queue…
}
}
finally
{
if (lockWasTaken)
{
Monitor.Exit(locker);
}
}
}
}
Another good alternative is to use Interlocked:
public static class Queue
{
static int status = 0;
public static void Process()
{
bool lockWasTaken = false;
try
{
lockWasTaken = Interlocked.CompareExchange(ref status, 1, 0) == 0;
if (lockWasTaken)
{
//Process Queue…
}
}
finally
{
if (lockWasTaken)
{
Volatile.Write(ref status, 0);
// For .NET Framework under .NET 4.5 use Thread.VolatileWrite instead.
}
}
}
}
Anyway, you don't have the need to implement your own thread-safe queue. You could use ConcurrentQueue.

A lock is good but it won't work for async await. You will get the following error if you try to await a method call in a lock:
CS1996 Cannot await in the body of a lock statement
In this case you should use a SemaphoreSlim
Example:
public class TestModel : PageModel
{
private readonly ILogger<TestModel> _logger;
private static readonly SemaphoreSlim _semaphoreSlim = new SemaphoreSlim(1, 1);
public TestModel(ILogger<TestModel> logger)
{
_logger = logger;
}
public async Task OnGet()
{
await _semaphoreSlim.WaitAsync();
try
{
await Stuff();
}
finally
{
_semaphoreSlim.Release();
}
}
}
It is important to not new SemaphoreSlim in the constructor or anywhere else because then it won't work.
https://stackoverflow.com/a/18257065/3850405
https://learn.microsoft.com/en-us/dotnet/api/system.threading.semaphoreslim?view=net-5.0

How to know who owns a ReaderWriterLockSlim?

I'm writting an application that does extensive use of multithreading. Some of the threads share an observablecollection using a ReaderWriterLockSlim.
I'm having from time to time a deadlock and I need to know which is the thread holding the lock at the moment of the deadlock. How can I know this? I've looked at the object properties and nothing obvious was there. Currently all I know is which threads are waiting for the lock.
Thanks for your help!
EDIT: Of course I'm talking about finding it at debug time with all the debug information available.

During your deadlock just look at the current threads in the thread debugging panel, go through your call stack and you'll find out which thread took the lock.
If you need to know the thread id in your code, you can always save it staticly, or inherit from readerwriterlockslim and add a thread property.

Here is what I meant.
Just trace the locks and unlocks and when you get to your deadlock the system will halt and the last "Enter" will point you in the direction of the locking thread.
public class ReaderWriterLockSlimExtended : ReaderWriterLockSlim
{
private Thread m_currentOwnerThread = null;
private object m_syncRoot = new object();
public Thread CurrentOwnerThread
{
get
{
lock (m_syncRoot)
{
return m_currentOwnerThread;
}
}
}
public Thread CurrentOwnerThreadUnsafe
{
get
{
return m_currentOwnerThread;
}
}
public new void EnterWriteLock()
{
lock (m_syncRoot)
{
base.EnterWriteLock();
m_currentOwnerThread = Thread.CurrentThread;
}
Debug.WriteLine("Enter Write Lock - Current Thread : {0} ({1})", CurrentOwnerThread.Name, CurrentOwnerThread.ManagedThreadId);
}
public new void ExitWriteLock()
{
Debug.WriteLine("Exit Write Lock - Current Thread : {0} ({1})", CurrentOwnerThread.Name, CurrentOwnerThread.ManagedThreadId);
lock (m_syncRoot)
{
m_currentOwnerThread = null; //Must be null before exit!
base.ExitWriteLock();
}
}
}

You can always try tracing the thread ID just before and after the lock, so you have written record of what happened and who locked it and when. You can write to a file or just check in the debugger output window to see all the traces.
I believe you could use trace breakpoint (Breakpoint -> When Hit...) instead of real tracing code to have quick something in the output window.

ReaderWriterLockSlim is not sealed so you could subclass it and attach whatever information you need that way. The problem is that the useful methods are not virtual so you cannot override them. But, you could add your own methods like EnterReadLockDebug and ExitReadLockDebug and the like which calls EnterReadLock and ExitReadLock behind the scenes in addition to capturing the thread in which the method is called. This is not a great solution because you would have to change all of the call sites. But, if using the debugger is too cumbersome then maybe this would be a reasonable alternative.
There are many variations to theme using conditional compilation. You could detect a Debug vs. Release build and inject the necessary debugging logic depending on which build configuration is active. Inject the debugging information when Debug is active and omit it when Release is active.

This is the code I ended with, for future reference:
using System;
using System.Threading;
namespace Utils
{
public class ReaderWriterLockSlim2
{
#region Attributes
private readonly TimeSpan _maxWait;
private readonly ReaderWriterLockSlim _lock;
#endregion
#region Properties
public int CurrentWriteOwnerId { get; private set; }
public string CurrentWriteOwnerName { get; private set; }
#endregion
#region Public Methods
public ReaderWriterLockSlim2(LockRecursionPolicy policy, TimeSpan maxWait)
{
_maxWait = maxWait;
_lock = new ReaderWriterLockSlim(policy);
}
public void EnterWriteLock()
{
if (!_lock.TryEnterWriteLock(_maxWait))
{
throw new TimeoutException(string.Format("Timeout while waiting to enter a WriteLock. Lock adquired by Id {0} - Name {1}", this.CurrentWriteOwnerId, this.CurrentWriteOwnerName));
}
else
{
this.CurrentWriteOwnerId = Thread.CurrentThread.ManagedThreadId;
this.CurrentWriteOwnerName = Thread.CurrentThread.Name;
}
}
public void ExitWriteLock()
{
_lock.ExitWriteLock();
this.CurrentWriteOwnerId = 0;
this.CurrentWriteOwnerName = null;
}
public void EnterReadLock()
{
_lock.EnterReadLock();
}
public void ExitReadLock()
{
_lock.ExitReadLock();
}
#endregion
}
}

(invalid way to) avoid double checked locks in C#

Is this a valid and optimized way to avoid double checked locks:
public class SomeBaseClass
{
protected static object InitializeLock = new object();
protected static bool IsInitialized = false;
public void SomeFunction()
{
if (!IsInitialized)
{
System.Threading.Thread.MemoryBarrier();
lock (InitializeLock)
{
// do init stuff
IsInitialized = true;
}
}
//Do stuff that have to happen when function is called
}
}
With this being the double-checked alternative:
public class SomeBaseClass
{
protected static object InitializeLock = new object();
protected static bool IsInitialized = false;
public void SomeFunction()
{
if (!IsInitialized)
{
lock (InitializeLock)
{
if (!IsInitialized)
{
// do init stuff
IsInitialized = true;
}
}
}
//Do stuff that have to happen when function is called
}
}

No, because thread switch can happen right after two threads pass if (!IsInitialized)
There is a great article where this topic is explained in context of creating singleton: http://csharpindepth.com/Articles/General/Singleton.aspx (by Jon Skeet)

This is the second time this question has come up today. See:
C# manual lock/unlock
The short answer to your question is no, that is absolutely not valid. If the non-volatile read of "IsInitialized" is reordered with respect to the non-volatile read of whatever state is being initialized then the code path never has a memory barrier on it of any sort, and therefore the reads can be re-ordered, and therefore "IsInitialized" can be true while the out-of-date cached uninitialized state is still good.
What you have to do is either (1) don't do double-checked locking; it is dangerous, or (2) ensure that there is always at least one volatile read of IsInitialized to prevent reads of the initialized state being moved backwards in time.

The MemoryBarrier call in your first example is completely superfluous since the subsequent lock call creates an implicit memory barrier anyway.
Even if you moved the memory barrier before the first IsInitialized check, the code is still unsafe: there's a window for the thread to be interrupted between the IsInitialized check and the lock statement. That's why you generally need a second IsInitialized check inside the lock block.

You can help the check by making the IsInitialized flag volatile which will prevent other threads from caching it (a very minor improvement since you're locking), but you still need the flag after you're locking. In other words, you can't avoid the double-checked lock unless you use some tricky initialization.
However, you can do away with the locks if you re-design your class and if you go to an optimistic approach of changing the state... this should work like a charm:
public class Internals
{
private readonly bool IsInitialized;
public Internals(bool initialized)
{
IsInitialized = initialized;
}
}
public class SomeBaseClass
{
protected static Internals internals = new Internals(false);
public void SomeFunction()
{
do
{
Internals previous = internals;
}while(!previous.IsInitialized && previous != Interlocked.CompareExchange(internals, new Internals(true), previous))
}
}

'using' statement vs 'try finally'

I've got a bunch of properties which I am going to use read/write locks on. I can implement them either with a try finally or a using clause.
In the try finally I would acquire the lock before the try, and release in the finally. In the using clause, I would create a class which acquires the lock in its constructor, and releases in its Dispose method.
I'm using read/write locks in a lot of places, so I've been looking for ways that might be more concise than try finally. I'm interested in hearing some ideas on why one way may not be recommended, or why one might be better than another.
Method 1 (try finally):
static ReaderWriterLock rwlMyLock_m = new ReaderWriterLock();
private DateTime dtMyDateTime_m
public DateTime MyDateTime
{
get
{
rwlMyLock_m .AcquireReaderLock(0);
try
{
return dtMyDateTime_m
}
finally
{
rwlMyLock_m .ReleaseReaderLock();
}
}
set
{
rwlMyLock_m .AcquireWriterLock(0);
try
{
dtMyDateTime_m = value;
}
finally
{
rwlMyLock_m .ReleaseWriterLock();
}
}
}
Method 2:
static ReaderWriterLock rwlMyLock_m = new ReaderWriterLock();
private DateTime dtMyDateTime_m
public DateTime MyDateTime
{
get
{
using (new ReadLock(rwlMyLock_m))
{
return dtMyDateTime_m;
}
}
set
{
using (new WriteLock(rwlMyLock_m))
{
dtMyDateTime_m = value;
}
}
}
public class ReadLock : IDisposable
{
private ReaderWriterLock rwl;
public ReadLock(ReaderWriterLock rwl)
{
this.rwl = rwl;
rwl.AcquireReaderLock(0);
}
public void Dispose()
{
rwl.ReleaseReaderLock();
}
}
public class WriteLock : IDisposable
{
private ReaderWriterLock rwl;
public WriteLock(ReaderWriterLock rwl)
{
this.rwl = rwl;
rwl.AcquireWriterLock(0);
}
public void Dispose()
{
rwl.ReleaseWriterLock();
}
}

From MSDN, using Statement (C# Reference)
The using statement ensures that Dispose is called even if an exception occurs while you are calling methods on the object. You can achieve the same result by putting the object inside a try block and then calling Dispose in a finally block; in fact, this is how the using statement is translated by the compiler. The code example earlier expands to the following code at compile time (note the extra curly braces to create the limited scope for the object):
{
Font font1 = new Font("Arial", 10.0f);
try
{
byte charset = font1.GdiCharSet;
}
finally
{
if (font1 != null)
((IDisposable)font1).Dispose();
}
}
So basically, it is the same code but with a nice automatic null-checks and an extra scope for your variable. The documentation also states that it "ensures the correct use of IDisposable object" so you might as well gets even better framework support for any obscure cases in the future.
So go with option 2.
Having the variable inside a scope that ends immediately after it's no longer needed is also a plus.

I definitely prefer the second method. It is more concise at the point of usage, and less error prone.
In the first case someone editing the code has to be careful not to insert anything between the Acquire(Read|Write)Lock call and the try.
(Using a read/write lock on individual properties like this is usually overkill though. They are best applied at a much higher level. A simple lock will often suffice here since the possibility of contention is presumably very small given the time the lock is held for, and acquiring a read/write lock is a more expensive operation than a simple lock).

Consider the possibility that both solutions are bad because they mask exceptions.
A try without a catch should obviously be a bad idea; see MSDN for why the using statement is likewise dangerous.
Note also Microsoft now recommends ReaderWriterLockSlim instead of ReaderWriterLock.
Finally, note that the Microsoft examples use two try-catch blocks to avoid these issues, e.g.
try
{
try
{
//Reader-writer lock stuff
}
finally
{
//Release lock
}
}
catch(Exception ex)
{
//Do something with exception
}
A simple, consistent, clean solution is a good goal, but assuming you can't just use lock(this){return mydateetc;}, you might reconsider the approach; with more info I'm sure Stack Overflow can help ;-)

I personally use the C# "using" statement as often as possible, but there are a few specific things that I do along with it to avoid the potential issues mentioned. To illustrate:
void doSomething()
{
using (CustomResource aResource = new CustomResource())
{
using (CustomThingy aThingy = new CustomThingy(aResource))
{
doSomething(aThingy);
}
}
}
void doSomething(CustomThingy theThingy)
{
try
{
// play with theThingy, which might result in exceptions
}
catch (SomeException aException)
{
// resolve aException somehow
}
}
Note that I separate the "using" statement into one method and the use of the object(s) into another method with a "try"/"catch" block. I may nest several "using" statements like this for related objects (I sometimes go three or four deep in my production code).
In my Dispose() methods for these custom IDisposable classes, I catch exceptions (but NOT errors) and log them (using Log4net). I have never encountered a situation where any of those exceptions could possibly affect my processing. The potential errors, as usual, are allowed to propagate up the call stack and typically terminate processing with an appropriate message (the error and stack trace) logged.
If I somehow encountered a situation where a significant exception could occur during Dispose(), I would redesign for that situation. Frankly, I doubt that will ever happen.
Meanwhile, the scope and cleanup advantages of "using" make it one of my most favorite C# features. By the way, I work in Java, C#, and Python as my primary languages, with lots of others thrown in here and there, and "using" is one of my most favorite language features all around because it is a practical, everyday workhorse.

I like the 3rd option
private object _myDateTimeLock = new object();
private DateTime _myDateTime;
public DateTime MyDateTime{
get{
lock(_myDateTimeLock){return _myDateTime;}
}
set{
lock(_myDateTimeLock){_myDateTime = value;}
}
}
Of your two options, the second option is the cleanest and easier to understand what's going on.

"Bunch of properties" and locking at the property getter and setter level looks wrong. Your locking is much too fine-grained. In most typical object usage, you'd want to make sure that you acquired a lock to access more than one property at the same time. Your specific case might be different but I kinda doubt it.
Anyway, acquiring the lock when you access the object instead of the property will significantly cut down on the amount of locking code you'll have to write.

DRY says: second solution. The first solution duplicates the logic of using a lock, whereas the second does not.

Try/Catch blocks are generally for exception handling, while using blocks are used to ensure that the object is disposed.
For the read/write lock a try/catch might be the most useful, but you could also use both, like so:
using (obj)
{
try { }
catch { }
}
so that you can implicitly call your IDisposable interface as well as make exception handling concise.

The following creates extension methods for the ReaderWriterLockSlim class that allow you to do the following:
var rwlock = new ReaderWriterLockSlim();
using (var l = rwlock.ReadLock())
{
// read data
}
using (var l = rwlock.WriteLock())
{
// write data
}
Here's the code:
static class ReaderWriterLockExtensions() {
/// <summary>
/// Allows you to enter and exit a read lock with a using statement
/// </summary>
/// <param name="readerWriterLockSlim">The lock</param>
/// <returns>A new object that will ExitReadLock on dispose</returns>
public static OnDispose ReadLock(this ReaderWriterLockSlim readerWriterLockSlim)
{
// Enter the read lock
readerWriterLockSlim.EnterReadLock();
// Setup the ExitReadLock to be called at the end of the using block
return new OnDispose(() => readerWriterLockSlim.ExitReadLock());
}
/// <summary>
/// Allows you to enter and exit a write lock with a using statement
/// </summary>
/// <param name="readerWriterLockSlim">The lock</param>
/// <returns>A new object that will ExitWriteLock on dispose</returns>
public static OnDispose WriteLock(this ReaderWriterLockSlim rwlock)
{
// Enter the write lock
rwlock.EnterWriteLock();
// Setup the ExitWriteLock to be called at the end of the using block
return new OnDispose(() => rwlock.ExitWriteLock());
}
}
/// <summary>
/// Calls the finished action on dispose. For use with a using statement.
/// </summary>
public class OnDispose : IDisposable
{
Action _finished;
public OnDispose(Action finished)
{
_finished = finished;
}
public void Dispose()
{
_finished();
}
}

I think method 2 would be better.
Simpler and more readable code in your properties.
Less error-prone since the locking code doesn't have to be re-written several times.

While I agree with many of the above comments, including the granularity of the lock and questionable exception handling, the question is one of approach. Let me give you one big reason why I prefer using over the try {} finally model... abstraction.
I have a model very similar to yours with one exception. I defined a base interface ILock and in it I provided one method called Acquire(). The Acquire() method returned the IDisposable object and as a result means that as long as the object I am dealing with is of type ILock that it can be used to do a locking scope. Why is this important?
We deal with many different locking mechanisms and behaviors. Your lock object may have a specific timeout that employs. Your lock implementation may be a monitor lock, reader lock, writer lock or spin lock. However, from the perspective of the caller all of that is irrelevant, what they care about is that the contract to lock the resource is honored and that the lock does it in a manner consistent with it's implementation.
interface ILock {
IDisposable Acquire();
}
class MonitorLock : ILock {
IDisposable Acquire() { ... acquire the lock for real ... }
}
I like your model, but I'd consider hiding the lock mechanics from the caller. FWIW, I've measured the overhead of the using technique versus the try-finally and the overhead of allocating the disposable object will have between a 2-3% performance overhead.

I'm surprised no one has suggested encapsulating the try-finally in anonymous functions. Just like the technique of instantiating and disposing of classes with the using statement, this keeps the locking in one place. I prefer this myself only because I'd rather read the word "finally" than the word "Dispose" when I'm thinking about releasing a lock.
class StackOTest
{
private delegate DateTime ReadLockMethod();
private delegate void WriteLockMethod();
static ReaderWriterLock rwlMyLock_m = new ReaderWriterLock();
private DateTime dtMyDateTime_m;
public DateTime MyDateTime
{
get
{
return ReadLockedMethod(
rwlMyLock_m,
delegate () { return dtMyDateTime_m; }
);
}
set
{
WriteLockedMethod(
rwlMyLock_m,
delegate () { dtMyDateTime_m = value; }
);
}
}
private static DateTime ReadLockedMethod(
ReaderWriterLock rwl,
ReadLockMethod method
)
{
rwl.AcquireReaderLock(0);
try
{
return method();
}
finally
{
rwl.ReleaseReaderLock();
}
}
private static void WriteLockedMethod(
ReaderWriterLock rwl,
WriteLockMethod method
)
{
rwl.AcquireWriterLock(0);
try
{
method();
}
finally
{
rwl.ReleaseWriterLock();
}
}
}

SoftwareJedi, I don't have an account, so I can't edit my answers.
In any case, the previous version wasn't really good for general purpose use since the read lock always required a return value. This fixes that:
class StackOTest
{
static ReaderWriterLock rwlMyLock_m = new ReaderWriterLock();
private DateTime dtMyDateTime_m;
public DateTime MyDateTime
{
get
{
DateTime retval = default(DateTime);
ReadLockedMethod(
delegate () { retval = dtMyDateTime_m; }
);
return retval;
}
set
{
WriteLockedMethod(
delegate () { dtMyDateTime_m = value; }
);
}
}
private void ReadLockedMethod(Action method)
{
rwlMyLock_m.AcquireReaderLock(0);
try
{
method();
}
finally
{
rwlMyLock_m.ReleaseReaderLock();
}
}
private void WriteLockedMethod(Action method)
{
rwlMyLock_m.AcquireWriterLock(0);
try
{
method();
}
finally
{
rwlMyLock_m.ReleaseWriterLock();
}
}
}

Actually in your first example, to make the solutions comparable, you would also implement IDisposable there as well. Then you'd call Dispose() from the finally block instead of releasing the lock directly.
Then you'd be "apples to apples" implementation (and MSIL)-wise (MSIL will be the same for both solutions). It's still probably a good idea to use using because of the added scoping and because the Framework will ensure proper usage of IDisposable (the latter being less beneficial if you're implementing IDisposable yourself).

Silly me. There's a way to make that even simpler by making the locked methods part of each instance (instead of static like in my previous post). Now I really prefer this because there's no need to pass `rwlMyLock_m' off to some other class or method.
class StackOTest
{
private delegate DateTime ReadLockMethod();
private delegate void WriteLockMethod();
static ReaderWriterLock rwlMyLock_m = new ReaderWriterLock();
private DateTime dtMyDateTime_m;
public DateTime MyDateTime
{
get
{
return ReadLockedMethod(
delegate () { return dtMyDateTime_m; }
);
}
set
{
WriteLockedMethod(
delegate () { dtMyDateTime_m = value; }
);
}
}
private DateTime ReadLockedMethod(ReadLockMethod method)
{
rwlMyLock_m.AcquireReaderLock(0);
try
{
return method();
}
finally
{
rwlMyLock_m.ReleaseReaderLock();
}
}
private void WriteLockedMethod(WriteLockMethod method)
{
rwlMyLock_m.AcquireWriterLock(0);
try
{
method();
}
finally
{
rwlMyLock_m.ReleaseWriterLock();
}
}
}