ReaderWriterLock appears to contain a deadlock

  • Thread starter Thread starter J.Marsch
  • Start date Start date
J

J.Marsch

Issue:
I have 3 threads, syncing with a ReaderWriterLock (in "real life", there
will be more).

Thread 1 (there could be any number of these) Gets a read lock with infinite
timeout. It runs in a loop. The readlocks are requested and released very
often.

Thread 2 (only one, this is my deadlock testing thread) represents a longer
running process. It gets a ReadLock as well.

(so far the world is good)

Thread 3 (timer thread, there will only ever be one of these) requests a
Write Lock with a 5 second timeout.

Thread 3 fails to get the WriteLock ApplicationException is thrown. This is
expected behavior as well -- the purpose of the test is to force the
writelock to time out.

Now here's the part that looks like a bug:
Even though Thread 3 failed to acquire the lock, the ReaderWriter stops
handing out Readlocks -- just like it would if the write lock were in force.
It does not resume handing out readlocks until Thread 2 releases its
readlock (presumably this frees an internal deadlock on the readerwriter
lock, allowing it to clear the failed write lock).

My problem: Using timeouts on ReaderWriterLocks appears to be a useless
gesture, as it appears to leave the structure in an unstable state.
Further, since the timeouts don't work, I'm left with a potential deadlock
in my applicaiton.

Have I got something wrong here, or is there a problem?
 
I have a Application that work almost in the same way, with N readers and N Writers (because the list of clients it's dynamic, and the use of the application too), in any moment, and for now the 2 work well, I have that the writers timeout in 5 seconds.


--
Bela Istok
MVP C#
Caracas, Venezuela
Issue:
I have 3 threads, syncing with a ReaderWriterLock (in "real life", there
will be more).

Thread 1 (there could be any number of these) Gets a read lock with infinite
timeout. It runs in a loop. The readlocks are requested and released very
often.

Thread 2 (only one, this is my deadlock testing thread) represents a longer
running process. It gets a ReadLock as well.

(so far the world is good)

Thread 3 (timer thread, there will only ever be one of these) requests a
Write Lock with a 5 second timeout.

Thread 3 fails to get the WriteLock ApplicationException is thrown. This is
expected behavior as well -- the purpose of the test is to force the
writelock to time out.

Now here's the part that looks like a bug:
Even though Thread 3 failed to acquire the lock, the ReaderWriter stops
handing out Readlocks -- just like it would if the write lock were in force.
It does not resume handing out readlocks until Thread 2 releases its
readlock (presumably this frees an internal deadlock on the readerwriter
lock, allowing it to clear the failed write lock).

My problem: Using timeouts on ReaderWriterLocks appears to be a useless
gesture, as it appears to leave the structure in an unstable state.
Further, since the timeouts don't work, I'm left with a potential deadlock
in my applicaiton.

Have I got something wrong here, or is there a problem?
 
Have you ever forced a timeout to occur (by holding a lock). Mine works great as long as you never actually timeout.
I have a Application that work almost in the same way, with N readers and N Writers (because the list of clients it's dynamic, and the use of the application too), in any moment, and for now the 2 work well, I have that the writers timeout in 5 seconds.


--
Bela Istok
MVP C#
Caracas, Venezuela
Issue:
I have 3 threads, syncing with a ReaderWriterLock (in "real life", there
will be more).

Thread 1 (there could be any number of these) Gets a read lock with infinite
timeout. It runs in a loop. The readlocks are requested and released very
often.

Thread 2 (only one, this is my deadlock testing thread) represents a longer
running process. It gets a ReadLock as well.

(so far the world is good)

Thread 3 (timer thread, there will only ever be one of these) requests a
Write Lock with a 5 second timeout.

Thread 3 fails to get the WriteLock ApplicationException is thrown. This is
expected behavior as well -- the purpose of the test is to force the
writelock to time out.

Now here's the part that looks like a bug:
Even though Thread 3 failed to acquire the lock, the ReaderWriter stops
handing out Readlocks -- just like it would if the write lock were in force.
It does not resume handing out readlocks until Thread 2 releases its
readlock (presumably this frees an internal deadlock on the readerwriter
lock, allowing it to clear the failed write lock).

My problem: Using timeouts on ReaderWriterLocks appears to be a useless
gesture, as it appears to leave the structure in an unstable state.
Further, since the timeouts don't work, I'm left with a potential deadlock
in my applicaiton.

Have I got something wrong here, or is there a problem?
 
I do a little test App to try: and i guest good results:

Enter: Fast Reader A0
Leave: Fast Reader A0
Enter: 10 sec Reader B0
Enter: 5 sec Wait Writer0
Enter: 5 sec Wait Writer1
Enter: 5 sec Wait Writer2
Enter: 5 sec Wait Writer3
Enter: 5 sec Wait Writer4
Enter: 5 sec Wait Writer5
Enter: 5 sec Wait Writer6
Enter: 5 sec Wait Writer7
Enter: 5 sec Wait Writer8
Enter: 5 sec Wait Writer9
Leave: 5 sec Wait Writer0
Leave: 5 sec Wait Writer1
Leave: 5 sec Wait Writer2
Leave: 5 sec Wait Writer3
Leave: 5 sec Wait Writer4
Leave: 5 sec Wait Writer5
Leave: 5 sec Wait Writer6
Leave: 5 sec Wait Writer7
Leave: 5 sec Wait Writer8
Leave: 5 sec Wait Writer9
Enter: Fast Reader A1
Leave: Fast Reader A1
Enter: 10 sec Reader B1
Enter: Fast Reader A2
Leave: Fast Reader A2
Enter: 10 sec Reader B2
Enter: Fast Reader A3
Leave: Fast Reader A3
Enter: 10 sec Reader B3
Enter: Fast Reader A4
Leave: Fast Reader A4
Enter: 10 sec Reader B4
Enter: Fast Reader A5
Leave: Fast Reader A5
Enter: 10 sec Reader B5
Enter: Fast Reader A6
Leave: Fast Reader A6
Enter: 10 sec Reader B6
Enter: Fast Reader A7
Leave: Fast Reader A7
Enter: 10 sec Reader B7
Enter: Fast Reader A8
Leave: Fast Reader A8
Enter: 10 sec Reader B8
Enter: Fast Reader A9
Leave: Fast Reader A9
Enter: 10 sec Reader B9
Leave: 10 sec Reader B0
Leave: 10 sec Reader B1
Leave: 10 sec Reader B2
Leave: 10 sec Reader B3
Leave: 10 sec Reader B4
Leave: 10 sec Reader B5
Leave: 10 sec Reader B6
Leave: 10 sec Reader B7
Leave: 10 sec Reader B8
Leave: 10 sec Reader B9

--
Bela Istok
MVP C#
Caracas, Venezuela
Have you ever forced a timeout to occur (by holding a lock). Mine works great as long as you never actually timeout.
I have a Application that work almost in the same way, with N readers and N Writers (because the list of clients it's dynamic, and the use of the application too), in any moment, and for now the 2 work well, I have that the writers timeout in 5 seconds.


--
Bela Istok
MVP C#
Caracas, Venezuela
Issue:
I have 3 threads, syncing with a ReaderWriterLock (in "real life", there
will be more).

Thread 1 (there could be any number of these) Gets a read lock with infinite
timeout. It runs in a loop. The readlocks are requested and released very
often.

Thread 2 (only one, this is my deadlock testing thread) represents a longer
running process. It gets a ReadLock as well.

(so far the world is good)

Thread 3 (timer thread, there will only ever be one of these) requests a
Write Lock with a 5 second timeout.

Thread 3 fails to get the WriteLock ApplicationException is thrown. This is
expected behavior as well -- the purpose of the test is to force the
writelock to time out.

Now here's the part that looks like a bug:
Even though Thread 3 failed to acquire the lock, the ReaderWriter stops
handing out Readlocks -- just like it would if the write lock were in force.
It does not resume handing out readlocks until Thread 2 releases its
readlock (presumably this frees an internal deadlock on the readerwriter
lock, allowing it to clear the failed write lock).

My problem: Using timeouts on ReaderWriterLocks appears to be a useless
gesture, as it appears to leave the structure in an unstable state.
Further, since the timeouts don't work, I'm left with a potential deadlock
in my applicaiton.

Have I got something wrong here, or is there a problem?
 
Back
Top