Matthias Blume <····@my.address.elsewhere> writes:
> Dirk Thierbach <··········@gmx.de> writes:
>
> > Erann Gat <···@jpl.nasa.gov> wrote:
> >
> > > But the ad-server was multi-threaded, and it turned out that
> > > there was a race condition.
> >
> > Nobody expects static typing to guard against race conditions.
>
> Why not?
>
> http://citeseer.nj.nec.com/boyapati01parameterized.html
There is also a technique in C++ which uses the type system and the
volatile keyword to guard against race conditions. I haven't used the
technique myself, so I don't know about benefits and problems. But it
sounds reasonable and might be of practical value. The technique
really relies on the language being statically typed.
One article describing it is here (sorry for the long URL):
http://www.informit.com/isapi/product_id~%7BE3967A89-4E20-425B-BCFF-B84B6DEED6CA%7D/content/index.asp
> > The same goes for unit tests: Even if you have quite a lot of them,
> > you probably would have been lucky if they caught the race condition.
>
> In fact, static analysis (although perhaps not in form of type
> systems) is your best (some may say: only) bet against the possibility
> of race conditions and their ilk.
The reason for this is that in a multithreaded environment you would
have to check an /exponential/ number of "different" programs (because
the scheduling might switch threads after each operation, in effect
creating a different control flow each time). IMHO, there is no
chance to fix a race condition in a moderately complex multithreaded
program by unit testing. (Note: I am /not/ saying a multithreaded
program shouldn't be unit-tested!)
From: Joe Marshall
Subject: Re: Why I don't believe in static typing
Date:
Message-ID: <ptfpvczm.fsf@ccs.neu.edu>
Matthias <··@spam.pls> writes:
> The reason for this is that in a multithreaded environment you would
> have to check an /exponential/ number of "different" programs (because
> the scheduling might switch threads after each operation, in effect
> creating a different control flow each time). IMHO, there is no
> chance to fix a race condition in a moderately complex multithreaded
> program by unit testing.
I disagree, but the technique isn't easy. The idea is to attempt to
*induce* the situations that lead to race conditions: heavy loads,
huge numbers of threads, rapid thread switching, etc. It can make
sense to put switches in the code that deliberately detune the system
to enhance the liklihood of races.