This is the situation described in Coding Horror:
On thread #1, our code was doing Log (lock) / DB stuff (lock)
On thread #2, our code was doing DB stuff (lock) / log stuff (lock)
The is a classic deadlock example. If thread #1 locks 'Log' at the same time
that thread #2 locks 'DB Stuff' then thread #1 will be waiting for the 'DB
stuff' lock to be freed before it can complete its work and thread #2 will be
waiting for the 'Log' lock to be freed before completing its work. Because
each is waiting on the other, neither will ever release its lock.
It is more likely to occur on heavily loaded, multi-core systems.
This problem is easily avoided by making sure that any code that needs both
resources applies the locks in the same order.
As was pointed out in the article, the problem was not a problem with log4net.
It really is not a even problem with logging. The problem was really bad code.
The author does make some good points about logging. While I do not
necessarily agree with everything he said, it is worth a read.
Cheers,
Jim
-----Original Message-----
From: koger [mailto:[EMAIL PROTECTED]
Sent: Friday, December 05, 2008 6:56 AM
To: [email protected]
Subject: Coding horror deadlock
Hi
Those of you who reads coding horror, might have seen this post:
http://www.codinghorror.com/blog/archives/001192.html.
Could somebody explain me how this deadlock happend? And how do I avoid to
get any deadlocks myself using log4net?
--
View this message in context:
http://www.nabble.com/Coding-horror-deadlock-tp20852380p20852380.html
Sent from the Log4net - Users mailing list archive at Nabble.com.
