Scope of ReaderWriterLocks

[Guest]

I am a bit new to threading and something is not clear about
ReaderWriterlocks. I understood that it meant that any so called shared
resource wil be locked, thus in the following example from my application the
object dataargs would be locked (even if its local and it makes no sense to
lock it) but what about the objects used in this.GetData?

Some objects used in this method are shred between at least two threads are
they locked or do I have to move my lock in the method itself?


internal void ThreadedReadData (object dataArguments){
DataExchange dataArgs;
try
{
rwLock.AcquireWriterLock(RegistryValues.Keys.ThreadWriterLocksTimeout);
try
{
dataArgs = (DataExchange)dataArguments;
dataArgs.dataset = this.GetData(dataArgs.datasetName, dataArgs.sessID,
dataArgs.parameters, false);
dataArgs.dataRead = true;
dataArguments = dataArgs;
}
finally{rwLock.ReleaseWriterLock();}
}
catch (ApplicationException e)
{
dataArgs = (DataExchange)dataArguments;
eventWriter.Write("The connection ID was " + this.Guid + "\nThe session ID
was " + dataArgs.sessID , e, 1016);
}
}

 

[Michel]

Hi Johnny,

A ReaderWriterlock simply gives you a mechanism to ensure only one thread
can access a resource (Write lock) if you want it to, and multiple threads
can access a resource with the Read lock. The lock is actually on the
ReaderWriterlock instance.
In your sample code, only one thread can access the code during the writer
lock. This includes the GetData call.

If you want to lock an actual instance of a class you could lock it using:
lock(obj) {
...
}

This puts a lock on obj, meaning no other thread can access the code if obj
is locked.

In your code sample, you could also have used lock(this) instead of the
Writer lock (or lock on a static object in the same class).
It really doesn't have a benefit to use ReaderWriterlock if you ONLY use the
Writer lock. The idea is that you use it in conjunction with Reader locks.

Hope this helps,
Michel

 

[Michel]

Hi Johnny,

Yes. I think you are doing the right thing ;-) This is exactly the reason to
use this type of lock.
Didn't know you were read-locking inside the GetData method. You must use
the same rwlock instance inside GetData, but I'm pretty sure you are doing
this.

Cheers,
Michel

 

[Guest]

So what you are saying is that all objects used by the GetData call are in
fact protected?. My idea is exactly that. Severall threads will be accessing
an object used by the GetData call but as readers, only this thread is a
writer to the shared object.

 

[Scott Allen]

So what you are saying is that all objects used by the GetData call are in
fact protected?. My idea is exactly that. Severall threads will be accessing
an object used by the GetData call but as readers, only this thread is a
writer to the shared object.

They are protected as long as any other threads that attempt to use
the objects are also acquiring the same lock. If you have another
method accessing the same objects that GetData uses, the method should
also be using rwLock. Make sense?

 

[Scott Allen]

In your code sample, you could also have used lock(this) instead of the
Writer lock (or lock on a static object in the same class).
It really doesn't have a benefit to use ReaderWriterlock if you ONLY use the
Writer lock. The idea is that you use it in conjunction with Reader locks.

As a general rule of thumb, lock(this) should be avoided. See Jon
Skeet's article section "Choosing what to lock on" in
http://www.yoda.arachsys.com/csharp/multithreading.html

Also, locking on a reference held in a static field can produce
drastially different behavior compared to locking on a reference in an
instance field.