CODEWITHSUNDEEP
.netmultithreadingthread-synchronization
Captain Sensible
Captain Sensible

Reputation: 5027

Avoiding deadlock with timeouts

I was just going through the MSDN article for the ReaderWriterLock class. The methods on the ReaderWriterLock class that allow us to acquire a lock all demand a timeout value when called. The MSDN article explains that this timeout value is used to avoid deadlocks: should a deadlock occur, the application will throw an ApplicationException when the lock times out.

The MSDN article then goes on to say:

A thread can catch this exception and determine what action to take next.

It seems to me that it would be very difficult to handle the ApplicationException above in a way that would allow the application to continue as if nothing of importance just happened. I have always assumed that a multithreaded application has to be designed in such a way that deadlocks cannot occur. Period. If a deadlock occurs it must be considered a design flaw or bug.

Is my assumption correct or is it entirely normal to use timeouts as a way of keeping the application churning forward ?

For reference: MSDN article

Upvotes: 1

Views: 529

Answers (1)

Ian Mercer
Ian Mercer

Reputation: 39277

It really depends on the application. In some cases it's more important to keep running at all costs and to discard data or tasks that aren't working for whatever reason including being blocked trying to get a lock. For example, a real-time system controlling the lights and heating should never fail just because it can't get a lock on the logging file.

In other cases data integrity is the most important consideration and stopping the app quickly is paramount once it has failed in some unexpected way.

Also bear in mind that the "action to take next" could be to exit and restart the application. The action may also be to log the failure and the steps leading up to it before restarting because knowing that will help someone debug why it deadlocked.

Upvotes: 1

Related Questions