ReaderWriterLock with Interlocked?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Amir The Ruler - 13 Jan 2007 20:57 GMT

Found this piece of code in .Net SDK 2.0. Why do we need to use Interlocked
although AcquireWriterLock is supposed to serialize access and do the traick?

// C#
ReaderWriterLock rwLock = new ReaderWriterLock();
int counter = 0;

try
{
rwLock.AcquireWriterLock(1000);

try
{
Interlocked.Increment(ref counter);
}
finally
{
rwLock.ReleaseWriterLock();
}
}
catch (ApplicationException)
{
Console.WriteLine("Failed to get a Writer Lock");
}

Thank you for any tips.

Reply to this Message

Barry Kelly - 13 Jan 2007 22:08 GMT

> Found this piece of code in .Net SDK 2.0. Why do we need to use Interlocked
> although AcquireWriterLock is supposed to serialize access and do the traick?
[quoted text clipped - 22 lines]
>
> Thank you for any tips.

That depends on whether 'counter' is used without synchronization
elsewhere in the body of code. If it isn't, then the locking is
redundant. (FWIW, it wouldn't be the first crappy piece of code in the
samples with the SDK & docs.)

-- Barry

Signature

http://barrkel.blogspot.com/

Reply to this Message

Michael Nemtsev - 14 Jan 2007 00:55 GMT

Hello Barry,

int (counter in our case) is atomic, afailk (if alignment wasn't changed).

Shouldn't this to be a reason to avoid Increment at all?!

---
WBR,
Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

BK> Amir The Ruler wrote:
BK>

>> Found this piece of code in .Net SDK 2.0. Why do we need to use
>> Interlocked although AcquireWriterLock is supposed to serialize
[quoted text clipped - 10 lines]
>> Interlocked.Increment(ref counter);
>> }

BK> That depends on whether 'counter' is used without synchronization
BK> elsewhere in the body of code. If it isn't, then the locking is
BK> redundant. (FWIW, it wouldn't be the first crappy piece of code in
BK> the samples with the SDK & docs.)

Reply to this Message

Barry Kelly - 14 Jan 2007 13:46 GMT

> int (counter in our case) is atomic, afailk (if alignment wasn't changed).
>
> Shouldn't this to be a reason to avoid Increment at all?!

Loads and assignments individually are atomic, but increment requires an
atomic combination of "load and increment and assignment" all in the one
"transaction". Thus either you need manual synchronization or
Interlocked.Increment etc.

Incrementing an int32 with a memory operand (e.g. 'inc dword ptr [eax]')
on a single-CPU x86 system, with no dual core and no hyperthreading, is
atomic. Other architectures, more CPUs, etc., almost certainly require
some kind of mutual exclusion or interlocked operation to work.

-- Barry

Signature

http://barrkel.blogspot.com/

Reply to this Message

Henning Krause [MVP - Exchange] - 14 Jan 2007 14:04 GMT

Hello,

> Loads and assignments individually are atomic, but increment requires an
> atomic combination of "load and increment and assignment" all in the one
> "transaction". Thus either you need manual synchronization or
> Interlocked.Increment etc.

However, reading a 64bit value on a 32bit architecture is not atomic and
must be protected as well...

Best regards,
Henning Krause

Reply to this Message

Barry Kelly - 14 Jan 2007 17:10 GMT

> Hello,
>
[quoted text clipped - 5 lines]
> However, reading a 64bit value on a 32bit architecture is not atomic and
> must be protected as well...

Of course, we're talking about an int here.

-- Barry

Signature

http://barrkel.blogspot.com/

Reply to this Message

Jon Skeet [C# MVP] - 14 Jan 2007 19:54 GMT

> int (counter in our case) is atomic, afailk (if alignment wasn't changed).
>
> Shouldn't this to be a reason to avoid Increment at all?!

No. Just because each operation (fetch/store) is atomic doesn't mean
that an increment (fetch/increment/store) is atomic:

counter=0

Thread 1 Thread 2
Fetch counter(0)
Fetch counter(0)
Increment (1)
Store (1)
Increment (1)
Store (1)

The result of two increments should be 2, but it's only 1.

Furthermore, atomic doesn't imply volatile - a fetch could see an old
value. See
http://www.pobox.com/~skeet/csharp/threads/volatility.shtml for more
information.

Signature

Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Reply to this Message

Amir The Ruler - 14 Jan 2007 02:24 GMT

actually that code is copied from MCTS Self-Paced Training Kit (Exam 70-536)
but i verified and found almost the same thing in sdk:

rwl.AcquireWriterLock(timeOut);
try
{
// It is safe for this thread to read or write
// from the shared resource.
resource = rnd.Next(500);
Display("writes resource value " + resource);
Interlocked.Increment(ref writes);

it yet doesn't make sense to use 2 sync mechanisms at once . and those
variables are not used anywhere else without synchronization.

> > Found this piece of code in .Net SDK 2.0. Why do we need to use Interlocked
> > although AcquireWriterLock is supposed to serialize access and do the traick?
[quoted text clipped - 29 lines]
>
> -- Barry

Reply to this Message

Rate this thread:

ReaderWriterLock with Interlocked?

Free Magazines