Re: Why I don't believe in static typing

Matthias Blume <[EMAIL PROTECTED]> writes:

> Dirk Thierbach <[EMAIL PROTECTED]> writes:
> 
> > Erann Gat <[EMAIL PROTECTED]> 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!)