Re: Threads and statics
On 4/9/2011 9:08 AM, Stefan Ram wrote:
Eric Sosman<esosman@ieee-dot-org.invalid> writes:
manipulates). Make sure the data is always seen in a consistent
state, except perhaps by the *one* thread that's in the act of
changing it; then you'll have a correct program.
It still could have potential deadlocks.
IIRC, deadlocks can happen when two threads each need two
resources and already have obtained access to one of them.
Each thread now waits for the other one to release the
other resource.
I have little knowledge about multithreading, but from this
it seems that one can avoid deadlocks as long as one can
avoid situations where more than one resource needs to be
obtained for exclusive access at the same time.
That is the trivial case, and is related to one of the simpler deadlock
avoidance strategies:
Establish a partial order among all lockable resources. Locking B while
holding A is safe if, and only if, A precedes B in the partial order.
From what I heard, for any realistic project, it is
impossible to be sure that one got this right. For example,
a program was written by experts in multithreading and then
showed a deadlock the first time after several years of use.
Successful multi-threading is most likely with a defense in depth.
Testing alone is not enough - a bug that happens once per thousand hours
of running some type of workload is difficult to find through testing,
but would cause a deadlock once per system per month at a site with the
right sort of workload.
There is often a temptation during testing to ignore failures that only
happen once and cannot be reproduced. If the development team gives in
to that temptation, testing becomes even less effective as bugs need to
be produced multiple times before they are taken seriously.
Theoretical analysis, such as defining a partial order and desk checking
or reviewing for correct use of the order, may also help.
Another line of attack on this is to look for ways of recovering from
deadlocks, such as applying database transaction concepts more widely.
Patricia