Thats not the issue I'm talking about.
void Method1()
{
lock(foo)
{
lock(bar)
{
// do something requiring foo and bar
}
}
}
void Method2()
{
lock(bar)
{
lock(foo)
{
// do something requiring foo and bar
}
}
}
If these two methods execute concurrently you have a reasonable chance of deadlock (a deadly embrace). The problem is the two threads will just halt and never continue so you are in an unrecoverable position that can't even supply any diagnostics. If you had a timeout in those lock statements you have the ability to realise that you cannot acquire a lock for some reason and that you have a deadlock situation. These can then be be logged and so diagnosed later. In some situation you can simply retry the operation and it succeeds as the other thread will have finished.
Regards
Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog http://www.dotnetconsult.co.uk
"Richard Blewett [DevelopMentor]" <ri******@NOSPAMdevelop.com> wrote in
news:eM**************@tk2msftngp13.phx.gbl:
Be careful with the lock keyword.
It doesn't take a timeout - infinite waits and multithreading are a
nasty source of deadlocks. It would be better to use Ian Griffiths'
TimedLock
http://www.interact-sw.co.uk/iangblo...retimedlocking
Regards
Richard Blewett
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk
Hi Richard,
I use similair code like this in the lock blocks:
dsWSCompany1.Clear();
daWSCompany.SelectCommand.CommandText = "select * from
company where name like '" + companyName + "'" + " order by name";
daWSCompany.Fill(dsWSCompany1);
return dsWSCompany1;
It's for an ASP.Net project. It's not very likely that this takes too
much time and the select command itself will time-out anyway.
Thanks for the warning, though. ;)
[microsoft.public.dotnet.languages.csharp]