You probably suspect the answer, typically its 'yes'
deadlock can occur in any multithreaded application.
Even ones that employ static members. Commonly it occurs
when more than one thread tries to lock a resource that
another thread has already locked.
A workaround is to use the Monitor object's TryEnter
method, and pass a timeout value, if timeout occurs the
method returns false.
This pattern will save you no end of pain and suffering,
check it out on MSDN. Also I would recommend that you
record the number of deadlock situations (TryEnters that
return false), that occur during your testing -at least
in your debug builds. This may lead you to redefine the
distribution of effort in your application if you find
that contention for resources is undermining efficiency.
Incidentally you may also wish to investigate another
threading bugbear, race conditions, where dirty reads and
overwrites may occur is shared resources are not securely
locked during operations.
HTH,
MK -----Original Message----- Is it possible to have deadlock in a multithreaded app
where there are nostatic members defined?
If so, in what ways and would you please provide a brief
sketch of anexample scenario? Thanks.
p-mon
. 8 2295
mk <mk@nospam.com> wrote: You probably suspect the answer, typically its 'yes' deadlock can occur in any multithreaded application. Even ones that employ static members. Commonly it occurs when more than one thread tries to lock a resource that another thread has already locked.
That's not necessarily a problem at all. Contention will reduce
performance, but that's not the same as deadlock. Deadlock occurs when
there is a cycle of two or more threads, where each thread in the path
wants a lock that the next thread holds, etc until you get round to the
last thread wanting the lock that the first thread holds. Often this is
with two threads, but it can certainly be with more than that.
A workaround is to use the Monitor object's TryEnter method, and pass a timeout value, if timeout occurs the method returns false. This pattern will save you no end of pain and suffering, check it out on MSDN. Also I would recommend that you record the number of deadlock situations (TryEnters that return false), that occur during your testing -at least in your debug builds. This may lead you to redefine the distribution of effort in your application if you find that contention for resources is undermining efficiency.
Incidentally you may also wish to investigate another threading bugbear, race conditions, where dirty reads and overwrites may occur is shared resources are not securely locked during operations.
I personally would avoid the "workaround" for almost everything.
Multithreading is fundamentally pretty nasty, but I firmly believe that
the only way to do it properly is to lock only where you're sure you
need to, always think about things so that you're sure one way or the
other, and clearly document thread safety. Testing will get you so far,
but race conditions and deadlocks always seem to end up happening in
the field rather than on test machines. A strong model of what should
go on is much, much better than a "try it and fix where it doesn't
work" approach. (You didn't exactly suggest that, but it seems to be
where it was going.)
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too
Hi,
Regarding contention v. deadlock you're quite correct, I
should have elaborated my example a little further.
Regarding your comments on 'workaround', I'm afraid that
not all multithreaded apps are deterministic. It does
depend on the runtime env. which can lead to
unpredictable behaviour in the field. Perhaps the
term 'workaround' was also a poor choice, what I meant
was that when in doubt, or where there is potential for
doubt, don't expose yourself to deadlock, and especially
so in distributed apps where networks may have failed, db
connections may have failed, etc. Rather, don't just
blindly call lock, give yourself an 'outie'.
Kind regards,
Martin -----Original Message----- mk <mk@nospam.com> wrote: You probably suspect the answer, typically its 'yes' deadlock can occur in any multithreaded application. Even ones that employ static members. Commonly it
occurs when more than one thread tries to lock a resource
that another thread has already locked. That's not necessarily a problem at all. Contention will
reduceperformance, but that's not the same as deadlock.
Deadlock occurs whenthere is a cycle of two or more threads, where each
thread in the pathwants a lock that the next thread holds, etc until you
get round to thelast thread wanting the lock that the first thread
holds. Often this iswith two threads, but it can certainly be with more than
that. A workaround is to use the Monitor object's TryEnter method, and pass a timeout value, if timeout occurs
the method returns false. This pattern will save you no end of pain and
suffering, check it out on MSDN. Also I would recommend that you record the number of deadlock situations (TryEnters
that return false), that occur during your testing -at
least in your debug builds. This may lead you to redefine
the distribution of effort in your application if you find that contention for resources is undermining
efficiency. Incidentally you may also wish to investigate another threading bugbear, race conditions, where dirty reads
and overwrites may occur is shared resources are not
securely locked during operations. I personally would avoid the "workaround" for almost
everything.Multithreading is fundamentally pretty nasty, but I
firmly believe thatthe only way to do it properly is to lock only where
you're sure youneed to, always think about things so that you're sure
one way or theother, and clearly document thread safety. Testing will
get you so far,but race conditions and deadlocks always seem to end up
happening inthe field rather than on test machines. A strong model
of what shouldgo on is much, much better than a "try it and fix where
it doesn'twork" approach. (You didn't exactly suggest that, but it
seems to bewhere it was going.)
-- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet/ If replying to the group, please do not mail me too .
mk <mk@nospam.com> wrote: Regarding contention v. deadlock you're quite correct, I should have elaborated my example a little further. Regarding your comments on 'workaround', I'm afraid that not all multithreaded apps are deterministic. It does depend on the runtime env. which can lead to unpredictable behaviour in the field. Perhaps the term 'workaround' was also a poor choice, what I meant was that when in doubt, or where there is potential for doubt, don't expose yourself to deadlock, and especially so in distributed apps where networks may have failed, db connections may have failed, etc. Rather, don't just blindly call lock, give yourself an 'outie'.
Hmm... While I can see that would *occasionally* be useful in those
circumstances (although if you've got a thread waiting forever for a
network connection or a database, you've got other major problems
anyway), I really wouldn't want to use it very often at all.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too
mk wrote: You probably suspect the answer, typically its 'yes' deadlock can occur in any multithreaded application. Even ones that employ static members. Commonly it occurs when more than one thread tries to lock a resource that another thread has already locked. A workaround is to use the Monitor object's TryEnter method, and pass a timeout value, if timeout occurs the method returns false. This pattern will save you no end of pain and suffering, check it out on MSDN. Also I would recommend that you record the number of deadlock situations (TryEnters that return false), that occur during your testing -at least in your debug builds. This may lead you to redefine the distribution of effort in your application if you find that contention for resources is undermining efficiency.
Incidentally you may also wish to investigate another threading bugbear, race conditions, where dirty reads and overwrites may occur is shared resources are not securely locked during operations.
Jon has said it all and I couldn't agree more. Multithreading is a all about
thinking very hard before you code and much less about trial and error. It
is always a very good idea to have MT code reviewed by someone who really
knows MT, *before you start integrating it*. Multithreading bugs are
tyically very hard to track down (deadlocks are easiest).
Regards,
Andreas
You think it would *occassionally* be useful in those
circumstances? Can you describe a situation where you
think the majority applies in those circumstances. I've
spent 20 years writing multithreaded distributed apps,
and we always protect ourselves against undeclared
resource outage.
Please understand that this is meant in uberrimae fides,
and not some attempt at flame-propagation.
I think that in the .Net scenario, C# in particular, we
don't always have full control, and we need to ensure
that attempts to acquire async resources should be
controlled.
Kind regards,
Martin -----Original Message----- mk <mk@nospam.com> wrote: Regarding contention v. deadlock you're quite correct,
I should have elaborated my example a little further. Regarding your comments on 'workaround', I'm afraid
that not all multithreaded apps are deterministic. It does depend on the runtime env. which can lead to unpredictable behaviour in the field. Perhaps the term 'workaround' was also a poor choice, what I meant was that when in doubt, or where there is potential
for doubt, don't expose yourself to deadlock, and
especially so in distributed apps where networks may have failed,
db connections may have failed, etc. Rather, don't just blindly call lock, give yourself an 'outie'. Hmm... While I can see that would *occasionally* be
useful in thosecircumstances (although if you've got a thread waiting
forever for anetwork connection or a database, you've got other major
problemsanyway), I really wouldn't want to use it very often at
all. -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet/ If replying to the group, please do not mail me too .
Andreas Huber <ah****@gmx.net> wrote: Jon has said it all and I couldn't agree more. Multithreading is a all about thinking very hard before you code and much less about trial and error. It is always a very good idea to have MT code reviewed by someone who really knows MT, *before you start integrating it*. Multithreading bugs are tyically very hard to track down (deadlocks are easiest).
The difficulty here is finding someone who really knows MT to start
with. I'd like to think I know more than most casual programmers, but I
wouldn't like to really certify things as safe :)
(I'm more than happy to lend my opinion, of course, as regulars here
are all too well aware ;)
One of my favourite understatements was on comp.lang.java.programmer,
from one of the very well respected regulars:
"Multi-threaded programming needs a little care."
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too
mk <mk@nospam.com> wrote: You think it would *occassionally* be useful in those circumstances?
I expressed it badly: I think it's occasionally useful, because I think
those circumstances occur rarely.
Can you describe a situation where you think the majority applies in those circumstances. I've spent 20 years writing multithreaded distributed apps, and we always protect ourselves against undeclared resource outage.
Surely it's only undeclared resource outage that has *already* tied up
a thread indefinitely that causes this problem, isn't it? That's what I
find pretty rare. Usually, if a network or database fails, the thread
isn't going to deadlock - the method is going to throw an exception or
return a failure code.
I guess you could end up making a request to a webserver or database
which deliberately holds the connection forever, or somesuch - but then
I think you're likely to be in deep problems already, and TryEnter
isn't going to help that much.
Please understand that this is meant in uberrimae fides, and not some attempt at flame-propagation. I think that in the .Net scenario, C# in particular, we don't always have full control, and we need to ensure that attempts to acquire async resources should be controlled.
It seems to me that by the time this kind of thing happens the program
is likely to be sufficiently screwed up that actually deadlock might be
one of the safest courses of action - it at least can't then corrupt
any data. The only other alternative (that I can see) is to abort the
program completely - you're probably no longer in a viable situation to
get on with work reliably. Admittedly that alternative may well be
better than deadlocking - at least in some ways.
Your suggestion came over as though the code should be peppered with
TryEnter. That necessitates manually calling Exit, which I suggest is
more likely to cause problems in the long run, as I suspect the average
developer is less likely to hit deadlock through catastrophic failure
than they are to cause bugs by failing to call Exit properly in all
cases, causing potential deadlock or even data corruption in far less
dire circumstances than the catastrophic ones talked about above.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too
mk <mk@nospam.com> wrote: I do agree. Naturally, so many of the rt vars apply to very specific scenarios. I didn't mean to suggest that TryEnter should be the prevalent means. I do hope that no offense was caused or taken. I do enjoy reading through this newsgroup from time to time, and always your responses show diligence.
Absolutely no offence taken - and to be honest, it sounds like you do
have a lot more experience in some very difficult scenarios than I do.
Apologies if I've pushed my corner a bit too hard, as it were :)
I suspect we've just miscommunicated/misunderstood the each other a bit
- but no harm is done on this side, and I hope the feeling's mutual.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Duncan Grisby |
last post by:
Hi,
Does anyone know of a deadlock detector for Python? I don't think it
would be too hard to hook into the threading module and instrument
mutexes so they can be tested for deadlocks. I've...
|
by: DanielBradley |
last post by:
Hello all,
I have recently been porting code from Linux to cygwin and came across
a problem with static const class members (discussed below). I am
seeking to determine whether I am programming...
|
by: Andrew Mayo |
last post by:
Here's a really weird one for any SQL Server gurus out there...
We have observed (SQL Server 2000) scenarios where a stored procedure
which
(a) begins a transaction
(b) inserts some rows into...
|
by: Zeng |
last post by:
Hi,
The bigger my C# web-application gets, the more places I need to put in the
tedious retrying block of code to make sure operations that can run into
database deadlocks are re-run (retried)...
|
by: Matik |
last post by:
Hello,
I've very often a deadlock problem.
The deadlock is generated always in the same way, by one application
calling in DB two sp's (application has two threads).
This is an error message...
|
by: Hemant Shah |
last post by:
Folks,
I have been getting SQLCODE -911 while reading data from a table.
When I look at the db2diag.log file I see following:
2006-10-10-14.33.13.384726-240 I127058C470 LEVEL: Warning...
|
by: |
last post by:
I have a db2 V. 8.1 Fix Pack 13 installed, and i have too much problem with
deadlock, maibe depends becouse i have a direct remote connection with a
56k modem.
Someone know if depends to a...
|
by: Zytan |
last post by:
This program DOESN'T deadlock due to attempt to reenter the same
lock! Why?
private static object m_lock = new object();
static void Main(string args)
{
lock (m_lock) { MyFunc(); }
}
|
by: Dragan |
last post by:
Hi,
We're working in VS 2005, Team edition, if it makes any difference at
all (should be up-to-date and all that, but could not guarantee it is
100%).
We've implemented a simple generic wrapper...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |